On Fri, Jul 08, 2022 at 02:34:25PM +0200, netdev@kapio-technology.com wrote:
On 2022-07-08 13:56, Vladimir Oltean wrote:
On Fri, Jul 08, 2022 at 11:50:33AM +0200, netdev@kapio-technology.com wrote:
On 2022-07-08 11:15, Vladimir Oltean wrote:
When the possibility for it to be true will exist, _all_ switchdev drivers will need to be updated to ignore that (mlxsw, cpss, ocelot, rocker, prestera, etc etc), not just DSA. And you don't need to propagate the is_locked flag to all individual DSA sub-drivers when none care about is_locked in the ADD_TO_DEVICE direction, you can just ignore within DSA until needed otherwise.
Maybe I have it wrong, but I think that Ido requested me to send it to all the drivers, and have them ignore entries with is_locked=true ...
I don't think Ido requested you to ignore is_locked from all DSA drivers, but instead from all switchdev drivers maybe. Quite different.
So without changing the signature on port_fdb_add(). If that is to avoid changing that signature, which needs to be changed anyhow for any switchcore driver to act on it, then my next patch set will change the signarure also as it is needed for creating dynamic ATU entries from userspace, which is needed to make the whole thing complete.
As it is already done (with the is_locked to the drivers) and needed for future application, I would like Ido to comment on it before I take action.
It's related to my reply here [1]. AFAICT, we have two classes of device drivers:
1. Drivers like mv88e6xxx that report locked entries to the bridge driver via 'SWITCHDEV_FDB_ADD_TO_BRIDGE'.
2. Drivers like mlxsw that trap packets that incurred an FDB miss to the bridge driver. These packets will cause the bridge driver to emit 'SWITCHDEV_FDB_ADD_TO_DEVICE' notifications with the locked flag.
If we can agree that locked entries are only meant to signal to user space that a certain MAC tried to gain authorization and that the bridge should ignore them while forwarding, then there is no point in generating the 'SWITCHDEV_FDB_ADD_TO_DEVICE' notifications. We should teach the bridge driver to suppress these so that there is no need to patch all the device drivers.
[1] https://lore.kernel.org/netdev/YsqLyxTRtUjzDj6D@shredder/
In any case I'm going to take a look at this patch set more closely and run the selftest on my Marvell switch, but I can't do this today unfortunately. I'll return with more comments.
Yes :-)