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@xxxxxxxxxxxx>
> >
> > 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@xxxxxxxxxxxxxxx # 5.1+
> > Signed-off-by: Daniel de Villiers <daniel.devilliers@xxxxxxxxxxxx>
> > Signed-off-by: Louis Peens <louis.peens@xxxxxxxxxxxx>
>
> 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.
>
> The code-change looks good to me.
>
