On Mon, Mar 27, 2023 at 11:49:58PM +0200, Hans Schultz wrote:
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.
Link to patch? I don't see any SWITCHDEV_FDB_ADD_TO_BRIDGE call in either the v1: https://lore.kernel.org/netdev/20230130173429.3577450-6-netdev@kapio-technol... or the RFC: https://lore.kernel.org/netdev/20230117185714.3058453-6-netdev@kapio-technol... and the change log does not mention it either.
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.
Actually, the part which you are now posing as a question (what is the difference?) was part of the premise of your earlier question (there is no difference => why do we have both?). https://lore.kernel.org/netdev/d972e76bed896b229d9df4da81ad8eb4@kapio-techno...
I believe that no one answered because the question was confused and it wasn't really clear what you were asking.
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)
which idea is that, again?