[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220708091550.2qcu3tyqkhgiudjg@skbuf>
Date: Fri, 8 Jul 2022 12:15:50 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: netdev@...io-technology.com
Cc: davem@...emloft.net, kuba@...nel.org, netdev@...r.kernel.org,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>, Jiri Pirko <jiri@...nulli.us>,
Ivan Vecera <ivecera@...hat.com>,
Roopa Prabhu <roopa@...dia.com>,
Nikolay Aleksandrov <razor@...ckwall.org>,
Shuah Khan <shuah@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Ido Schimmel <idosch@...dia.com>, linux-kernel@...r.kernel.org,
bridge@...ts.linux-foundation.org, linux-kselftest@...r.kernel.org
Subject: Re: [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@...io-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@...io-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(-)
Powered by blists - more mailing lists