On Wed, Jan 18, 2023 at 11:35:08PM +0100, netdev@kapio-technology.com wrote:

I am not sure I understand you entirely.
From my standpoint I see it as so: that until now any fdb entry coming to
port_fdb_add() (or port_fdb_del()) are seen as static entries. And this
changes nothing with respect to those static entries as how drivers handle
them.

This is true; it is implicit that the port_fdb_add() and port_fdb_del()
DSA methods request switches to operate on static FDB entries (in hardware).

When the new dynamic flag is true, all drivers will ignore it in patch #3,
so basically nothing will change by that.

This is not true, because it assumes that DSA never called port_fdb_add()
up until now for bridge FDB entries with the BR_FDB_STATIC flag unset,
which is incorrect (it did).

So what will change is that drivers which used to react to those bridge
FDB entries will stop doing so.

Then in patch #5 the dynamic flag is handled by the mv88e6xxx driver.

I don't know the assisted_learning_on_cpu_port feature you mention, but
there has still not been anything but static entries going towards
port_fdb_add() yet...

For starters, you can read the commit message of the patch that
introduced it, which is d5f19486cee7 ("net: dsa: listen for
SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors").