On 2022-07-10 10:35, Ido Schimmel wrote:

On Fri, Jul 08, 2022 at 02:34:25PM +0200, netdev@kapio-technology.com 
wrote:

quoted

On 2022-07-08 13:56, Vladimir Oltean wrote:

quoted

On Fri, Jul 08, 2022 at 11:50:33AM +0200, netdev@kapio-technology.com
wrote:

quoted

On 2022-07-08 11:15, Vladimir Oltean wrote:

quoted

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.

I do not know of all about what other switchcores there are and how they 
work, but those that I have knowledge of, it has been prudent in 
connection with the locked port feature to install Storm Prevention or 
zero-DPV (Destination Port Vector) FDB entries. I would think that that 
should be the case for other switchcores too.
Those entries cannot normally be installed from userspace (of course 
special tools can do anything).

But if the decision is to drop locked entries at the DSA layer, I can do 
that. I just want to ensure that all considerations have been taken.

[1] https://lore.kernel.org/netdev/YsqLyxTRtUjzDj6D@shredder/ (local)

quoted

quoted

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 :-)