On Mon, Aug 22, 2022 at 09:49:28AM +0200, netdev@xxxxxxxxxxxxxxxxxxxx wrote: > On 2022-08-22 07:40, Ido Schimmel wrote: > > On Sun, Aug 21, 2022 at 03:43:04PM +0200, netdev@xxxxxxxxxxxxxxxxxxxx > > wrote: > > > > I personally think that the mv88e6xxx semantics are very weird (e.g., no > > roaming, traffic blackhole) and I don't want them to determine how the > > feature works in the pure software bridge or other hardware > > implementations. On the other hand, I understand your constraints and I > > don't want to create a situation where user space is unable to > > understand how the data path works from the bridge FDB dump with > > mv88e6xxx. > > > > My suggestion is to have mv88e6xxx report the "locked" entry to the > > bridge driver with additional flags that describe its behavior in terms > > of roaming, ageing and forwarding. > > > > In terms of roaming, since in mv88e6xxx the entry can't roam you should > > report the entry with the "sticky" flag. > > As I am not familiar with roaming in this context, I need to know how the SW > bridge should behave in this case. I think I wasn't clear enough. The idea is to make the bridge compatible with mv88e6xxx in a way that is discoverable by user space by having mv88e6xxx add the locked entry with flags that describe the hardware behavior. Therefore, it's not a matter of "how the SW bridge should behave", but having it behave in a way that matches the offloaded data path. >From what I was able to understand from you, the "locked" entry cannot roam at all in mv88e6xxx, which can be described by the "sticky" flag. > In this I am assuming that roaming is regarding unauthorized entries. Yes, talking about "locked" entries that are notified by mv88e6xxx to the bridge. > 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. > > > In terms of ageing, since > > mv88e6xxx is the one doing the ageing and not the bridge driver, report > > the entry with the "extern_learn" flag. > > Just for the record, I see that entries coming from the driver to the bridge > will always have the "extern learn" flag set as can be seen from the > SWITCHDEV_FDB_ADD_TO_BRIDGE events handling in br_switchdev_event() in br.c, > which I think is the correct behavior. Yes. > > > In terms of forwarding, in > > mv88e6xxx the entry discards all matching packets. We can introduce a > > new FDB flag that instructs the entry to silently discard all matching > > packets. Like we have with blackhole routes and nexthops. > > Any suggestions to the name of this flag? I'm not good at naming, but "blackhole" is at least consistent with what we already have for routes and nexthop objects. > > > > > I believe that the above suggestion allows you to fully describe how > > these entries work in mv88e6xxx while keeping the bridge driver in sync > > with complete visibility towards user space. > > > > It also frees the pure software implementation from the constraints of > > mv88e6xxx, allowing "locked" entries to behave like any other > > dynamically learned entries modulo the fact that they cannot "unlock" a > > locked port. > > > > Yes, it does mean that user space will get a bit different behavior with > > mv88e6xxx compared to a pure software solution, but a) It's only the > > corner cases that act a bit differently. As a whole, the feature works > > largely the same. b) User space has complete visibility to understand > > the behavior of the offloaded data path. > > > > > > > > > I will change it in iproute2 to: > > > bridge link set dev DEV mab on|off > > > > And s/BR_PORT_MACAUTH/BR_PORT_MAB/ ? > > Sure, I will do that. :-) Thanks
