On Tue, Mar 28, 2023 at 01:04:23PM +0200, Hans Schultz wrote:
On Tue, Mar 28, 2023 at 01:59, Vladimir Oltean olteanv@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'.
Why not? I find it reasonable that the software bridge does not age out a dynamic FDB entry that is offloaded to hardware... the hardware should do that ("dynamic" being the key). At least, I find it more reasonable than the current behavior, where the bridge notifies dynamic FDB entries to switchdev, but doesn't say they're dynamic, and switchdev treats them as static, so they don't roam from one bridge port to another until software sees a packet with that MAC DA, and they have the potential of blocking traffic because of that.
If for some reason you do think that behavior is useful and still want to keep it (I'm not sure I would), I would consider extending struct switchdev_notifier_fdb_info with a "bool pls_dont_age_out", and I would make dsa_fdb_offload_notify() set this to true if the driver did actually install the dynamic FDB entry as dynamic in the ATU.
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.
Basically you're suggesting that the hardware driver, after receiving a SWITCHDEV_FDB_ADD_TO_DEVICE and responding to it with SWITCHDEV_FDB_OFFLOADED, emits a SWITCHDEV_FDB_ADD_TO_BRIDGE which takes over that software bridge FDB entry, with the advantage that the new one already has the semantics of not being aged out by the software bridge.
hmmm... I'd say that the flow should work even with a single notifier emitted from the driver side, which would be SWITCHDEV_FDB_OFFLOADED, perhaps annotated with some qualifiers that would inform the bridge a certain behavior is required. Although, as mentioned, I think that in principle, "pls_dont_age_out" should be unnecessary, because it just papers over the issue that switchdev drivers treat static and dynamic FDB entries just the same, and "pls_dont_age_out" would be the differentiator for an issue that should have been solved elsewhere, as it could lead to other problems of its own.
Basically we're designing around a workaround to a problem to which we're turning a blind eye. These are my 2c.