On Mon, Feb 05, 2024 at 04:15:08PM +0200, Louis Peens wrote:
On Mon, Feb 05, 2024 at 01:32:03PM +0000, Simon Horman wrote:
On Fri, Feb 02, 2024 at 01:37:18PM +0200, Louis Peens wrote:
From: Daniel de Villiers daniel.devilliers@corigine.com
When physical ports are reset (either through link failure or manually toggled down and up again) that are slaved to a Linux bond with a tunnel endpoint IP address on the bond device, not all tunnel packets arriving on the bond port are decapped as expected.
The bond dev assigns the same MAC address to itself and each of its slaves. When toggling a slave device, the same MAC address is therefore offloaded to the NFP multiple times with different indexes.
The issue only occurs when re-adding the shared mac. The nfp_tunnel_add_shared_mac() function has a conditional check early on that checks if a mac entry already exists and if that mac entry is global: (entry && nfp_tunnel_is_mac_idx_global(entry->index)). In the case of a bonded device (For example br-ex), the mac index is obtained, and no new index is assigned.
We therefore modify the conditional in nfp_tunnel_add_shared_mac() to check if the port belongs to the LAG along with the existing checks to prevent a new global mac index from being re-assigned to the slave port.
Fixes: 20cce8865098 ("nfp: flower: enable MAC address sharing for offloadable devs") CC: stable@vger.kernel.org # 5.1+ Signed-off-by: Daniel de Villiers daniel.devilliers@corigine.com Signed-off-by: Louis Peens louis.peens@corigine.com
Hi Daniel and Louis,
I'd like to encourage you to update the wording of the commit message to use more inclusive language; I'd suggest describing the patch in terms of members of a LAG.
Thanks Simon, this have not even crossed my mind this time and I feel bad - I should be more aware. Thanks for politely pointing this out. This did get merged earlier today as-is unfortunately, I'm not sure if there is a good way (or if it is pressing enough) to have it retracted. I will try to be more cognizant of this in the future.
Hi Louis,
thanks for acknowledging my concern.
Given that the patch has been applied, I think it would be best to do as you suggest, and keep this in mind for next time.