Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers

On Tue, Aug 23, 2022 at 09:37:54AM +0200, netdev@kapio-technology.com wrote:

On 2022-08-23 09:24, Ido Schimmel wrote:

quoted

On Tue, Aug 23, 2022 at 09:13:54AM +0200, netdev@kapio-technology.com
wrote:

quoted

On 2022-08-23 08:48, Ido Schimmel wrote:

quoted

On Mon, Aug 22, 2022 at 09:49:28AM +0200, netdev@kapio-technology.com
wrote:

quoted

quoted

As I am not familiar with roaming in this context, I need to know
how the SW
bridge should behave in this case.

quoted

quoted

In this case, is the roaming only between locked ports or does the
roaming include that the entry can move to a unlocked port, resulting
in the locked flag getting removed?

Any two ports. If the "locked" entry in mv88e6xxx cannot move once
installed, then the "sticky" flag accurately describes it.

But since I am also doing the SW bridge implementation without
mv88e6xxx I
need it to function according to needs.
Thus the locked entries created in the bridge I shall not put the
sticky
flag on, but there will be the situation where a locked entry can
move to an
unlocked port, which we regarded as a bug.

I do not regard this as a bug. It makes sense to me that an authorized
port can cause an entry pointing to an unauthorized port to roam to
itself. Just like normal learned entries. What I considered as a bug is
the fact that the "locked" flag is not cleared when roaming to an
authorized port.

quoted

In that case there is two possibilities, the locked entry can move to
an unlocked port with the locked flag being removed or the locked
entry can only move to another locked port?

My suggestion is to allow roaming and maintain / clear the "locked" flag
based on whether the new destination port is locked or not.

Thus I understand it as saying that the "locked" flag can also be set when
roaming from an unlocked port to a locked port?

"learning on locked on" is really a misconfiguration, but it can also
happen today and entries do not roam with the "locked" flag for the
simple reason that it does not exist. I see two options:

1. Do not clear / set "locked" flag during roaming. Given learning
should be disabled on locked ports, then the only half interesting case
is roaming to an unlocked port. Keeping the "locked" flag basically
means "if you were to lock the port, then the presence of this entry is
not enough to let traffic with the SA be forwarded by the bridge".
Unlikely that anyone will do that.

2. Always set "locked" flag for learned entries (new & roamed) on locked
ports and clear it for learned entries on unlocked ports.

Both options are consistent in how they treat the "locked" flag (either
always do nothing or always set/clear) and both do not impact the
integrity of the solution when configured correctly (disabling learning
on locked ports). I guess users will find option 2 easier to understand
/ work with.