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@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.
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.
