netdev at kapio-technology.com
2022-Jul-08 09:06 UTC
[Bridge] [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers
On 2022-07-08 10:49, Vladimir Oltean wrote:> Hi Hans, > > On Thu, Jul 07, 2022 at 05:29:27PM +0200, Hans Schultz wrote: >> Ignore locked fdb entries coming in on all drivers. >> >> Signed-off-by: Hans Schultz <netdev at kapio-technology.com> >> --- > > A good patch should have a reason for the change in the commit message. > This has no reason because there is no reason. > > Think about it, you've said it yourself in patch 1: > > | Only the kernel can set this FDB entry flag, while userspace can read > | the flag and remove it by replacing or deleting the FDB entry. > > So if user space will never add locked FDB entries to the bridge, > then FDB entries with is_locked=true are never transported using > SWITCHDEV_FDB_ADD_TO_DEVICE to drivers, and so, there is no reason at > all to pass is_locked to drivers, just for them to ignore something > that > won't appear.Correct me if I am wrong, but since the bridge can add locked entries, and the ensuring fdb update will create a SWITCHDEV_FDB_ADD_TO_DEVICE, those entries should reach the driver. The policy to ignore those in the driver can be seen as either the right thing to do, or not yet implemented. I remember Ido wrote at a point that the scheme they use is to trap various packets to the CPU and let the bridge add the locked entry, which I then understand is sent to the driver with a SWITCHDEV_FDB_ADD_TO_DEVICE event.> > You just need this for SWITCHDEV_FDB_ADD_TO_BRIDGE, so please keep it > only in those code paths, and remove it from net/dsa/slave.c as well. > >> drivers/net/dsa/b53/b53_common.c | 5 +++++ >> drivers/net/dsa/b53/b53_priv.h | 1 + >> drivers/net/dsa/hirschmann/hellcreek.c | 5 +++++ >> drivers/net/dsa/lan9303-core.c | 5 +++++ >> drivers/net/dsa/lantiq_gswip.c | 5 +++++ >> drivers/net/dsa/microchip/ksz9477.c | 5 +++++ >> drivers/net/dsa/mt7530.c | 5 +++++ >> drivers/net/dsa/mv88e6xxx/chip.c | 5 +++++ >> drivers/net/dsa/ocelot/felix.c | 5 +++++ >> drivers/net/dsa/qca8k.c | 5 +++++ >> drivers/net/dsa/sja1105/sja1105_main.c | 5 +++++ >> include/net/dsa.h | 1 + >> net/dsa/switch.c | 4 ++-- >> 13 files changed, 54 insertions(+), 2 deletions(-)
Vladimir Oltean
2022-Jul-08 09:15 UTC
[Bridge] [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers
On Fri, Jul 08, 2022 at 11:06:24AM +0200, netdev at kapio-technology.com wrote:> On 2022-07-08 10:49, Vladimir Oltean wrote: > > Hi Hans, > > > > On Thu, Jul 07, 2022 at 05:29:27PM +0200, Hans Schultz wrote: > > > Ignore locked fdb entries coming in on all drivers. > > > > > > Signed-off-by: Hans Schultz <netdev at kapio-technology.com> > > > --- > > > > A good patch should have a reason for the change in the commit message. > > This has no reason because there is no reason. > > > > Think about it, you've said it yourself in patch 1: > > > > | Only the kernel can set this FDB entry flag, while userspace can read > > | the flag and remove it by replacing or deleting the FDB entry. > > > > So if user space will never add locked FDB entries to the bridge, > > then FDB entries with is_locked=true are never transported using > > SWITCHDEV_FDB_ADD_TO_DEVICE to drivers, and so, there is no reason at > > all to pass is_locked to drivers, just for them to ignore something that > > won't appear. > > Correct me if I am wrong, but since the bridge can add locked entries, and > the ensuring fdb update will create a SWITCHDEV_FDB_ADD_TO_DEVICE, those > entries > should reach the driver. The policy to ignore those in the driver can be > seen as either the right thing to do, or not yet implemented. > > I remember Ido wrote at a point that the scheme they use is to trap various > packets to the CPU and let the bridge add the locked entry, which I then > understand is sent to the driver with a SWITCHDEV_FDB_ADD_TO_DEVICE event.Well, yes, but if I'm correct, the bridge right now can't create locked FDB entries, so is_locked will always be false in the ADD_TO_DEVICE direction. 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.> > > > You just need this for SWITCHDEV_FDB_ADD_TO_BRIDGE, so please keep it > > only in those code paths, and remove it from net/dsa/slave.c as well. > > > > > drivers/net/dsa/b53/b53_common.c | 5 +++++ > > > drivers/net/dsa/b53/b53_priv.h | 1 + > > > drivers/net/dsa/hirschmann/hellcreek.c | 5 +++++ > > > drivers/net/dsa/lan9303-core.c | 5 +++++ > > > drivers/net/dsa/lantiq_gswip.c | 5 +++++ > > > drivers/net/dsa/microchip/ksz9477.c | 5 +++++ > > > drivers/net/dsa/mt7530.c | 5 +++++ > > > drivers/net/dsa/mv88e6xxx/chip.c | 5 +++++ > > > drivers/net/dsa/ocelot/felix.c | 5 +++++ > > > drivers/net/dsa/qca8k.c | 5 +++++ > > > drivers/net/dsa/sja1105/sja1105_main.c | 5 +++++ > > > include/net/dsa.h | 1 + > > > net/dsa/switch.c | 4 ++-- > > > 13 files changed, 54 insertions(+), 2 deletions(-)