Vladimir Oltean
2023-Mar-27 22:59 UTC
[Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
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 at kapio-technology.com/ or the RFC: https://lore.kernel.org/netdev/20230117185714.3058453-6-netdev at kapio-technology.com/ 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 at kapio-technology.com/ 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?
Hans Schultz
2023-Mar-28 11:04 UTC
[Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
On Tue, Mar 28, 2023 at 01:59, Vladimir Oltean <olteanv at gmail.com> wrote:> > which idea is that, again?So I cannot us the offloaded flag as it is added by DSA in the common case when using 'bridge fdb replace ... dynamic'. The idea is then to use the ext_learn flag instead, which is not aged by the bridge. To do this the driver (mv88e6xxx) will send a SWITCHDEV_FDB_ADD_TO_BRIDGE switchdev event when the new dynamic flag is true. The function sending this event will then be named mv88e6xxx_add_fdb_synth_learned() in drivers/net/dsa/mv88e6xxx/switchdev.c, replacing the mv88e6xxx_set_fdb_offloaded() function but in most part the same content, just another event type.
Apparently Analagous Threads
- [Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
- [Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
- [Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
- [Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
- [Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers