Linux Ethernet Bridging - Aug 2022 - [Bridge] [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers

On 2022-08-23 08:48, Ido Schimmel wrote:
> On Mon, Aug 22, 2022 at 09:49:28AM +0200, netdev at kapio-technology.com 
> wrote:
>> As I am not familiar with roaming in this context, I need to know how 
>> the SW
>> bridge should behave in this case.
> 
>> 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. 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?

On Tue, Aug 23, 2022 at 09:13:54AM +0200, netdev at kapio-technology.com
wrote:
> On 2022-08-23 08:48, Ido Schimmel wrote:
> > On Mon, Aug 22, 2022 at 09:49:28AM +0200, netdev at
kapio-technology.com
> > wrote:
> 
> > > As I am not familiar with roaming in this context, I need to know
> > > how the SW
> > > bridge should behave in this case.
> > 
> 
> > > 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.
> 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.