Linux Ethernet Bridging - Apr 2023 - [Bridge] [PATCH net] net: bridge: switchdev: don't notify FDB entries with "master dynamic"

On Wed, Apr 12, 2023 at 05:15:03PM +0300, Ido Schimmel
wrote:
> > Looking at tools/testing/selftests/net/forwarding/, there is no valid
> > use of the "bridge fdb add ... master dynamic" command
there, so I am
> > fairly confident that no one used to rely on this behavior.
> 
> Yes, but there are tests that use "extern_learn". If you post a
v2 that
> takes "BR_FDB_ADDED_BY_EXT_LEARN" into account, then I can ask
Petr to
> run it through our regression and report back (not sure we will make it
> to this week's PR though).
> 
> Thanks
How are extern_learn FDB entries processed by spectrum's
SWITCHDEV_FDB_ADD_TO_DEVICE handler?

On Wed, Apr 12, 2023 at 05:27:33PM +0300, Vladimir Oltean
wrote:
> How are extern_learn FDB entries processed by spectrum's
> SWITCHDEV_FDB_ADD_TO_DEVICE handler?
No different than "BR_FDB_STATIC", which is a bug I'm aware of and
intend to fix in net-next when I get the time (together with all the
other combinations enabled by the bridge). Entry has ageing disabled,
but can roam in which case it becomes age-able.

TBH, I think most devices don't handle "BR_FDB_STATIC" correctly.
In the
Linux bridge, "BR_FDB_STATIC" only means ageing disabled. The entry
can
still roam, but remains "static". I believe that in most devices out
there "static" means no roaming and no ageing which is equivalent to
"BR_FDB_STATIC | BR_FDB_STICKY". Mentioned in your commit message as
well: "As for the hardware FDB entry, that's static, it doesn't
move
when the station roams."

As it stands, the situation is far from perfect, but the patch doesn't
solve a regression (always broken) and will introduce one. My suggestion
allows you to move forward and solve the "dynamic" case, so let's
proceed with that unless there's a better alternative.