On Mon, Mar 27, 2023 at 19:00, Vladimir Oltean olteanv@gmail.com wrote:
A reasonable question you could ask yourself is: why do my BR_FDB_OFFLOADED entries have this flag in the software bridge in the first place? Did I add code for it? Is it because there is some difference between mv88e6xxx and ocelot/felix, or is it because dsa_fdb_offload_notify() gets called in both cases from generic code just the same?
And if dsa_fdb_offload_notify() gets called in both cases just the same, but no other driver except for mv88e6xxx emits the SWITCHDEV_FDB_DEL_TO_BRIDGE which you've patched the bridge to expect in this series, then what exactly is surprising in the fact that offloaded and dynamic FDB entries now become stale, but are not removed from the software bridge as they were before?
Yes, I see I have missed that the dsa layer already adds the offloaded flag in dsa_slave_switchdev_event_work() in slave.c.
My first approach was to use the SWITCHDEV_FDB_ADD_TO_BRIDGE event and not the SWITCHDEV_FDB_OFFLOADED event as the first would set the external learned flag which is not aged out by the bridge. I have at some point earlier asked why there would be two quite equivalent flags and what the difference between them are, but I didn't get a response.
Now I see the difference and that I cannot use the offloaded flag without changing the behaviour of the system as I actually change the behaviour of the offloaded flag in this version of the patch-set.
So if the idea of a 'synthetically' learned fdb entry from the driver using the SWITCHDEV_FDB_ADD_TO_BRIDGE event from the driver towards the bridge instead is accepted, I can go with that? (thus removing all the changes in the patch-set regarding the offloaded flag ofcourse)