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. In this I am assuming that
roaming is regarding unauthorized entries.
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?
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.
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 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. :-)
