From: Ido Schimmel <idosch@nvidia.com>
To: netdev@kapio-technology.com
Cc: Vladimir Oltean <olteanv@gmail.com>,
davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org,
Andrew Lunn <andrew@lunn.ch>,
Vivien Didelot <vivien.didelot@gmail.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Jiri Pirko <jiri@resnulli.us>,
Ivan Vecera <ivecera@redhat.com>, Roopa Prabhu <roopa@nvidia.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
Shuah Khan <shuah@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org,
linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers
Date: Wed, 13 Jul 2022 15:39:42 +0300 [thread overview]
Message-ID: <Ys69DiAwT0Md+6ai@shredder> (raw)
In-Reply-To: <d3f674dc6b4f92f2fda3601685c78ced@kapio-technology.com>
On Wed, Jul 13, 2022 at 09:09:58AM +0200, netdev@kapio-technology.com wrote:
> On 2022-07-10 10:35, Ido Schimmel wrote:
> > 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.
>
> 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.
What are "Storm Prevention" and "zero-DPV" 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.
There is no decision that I'm aware of. I'm simply trying to understand
how FDB entries that have 'BR_FDB_ENTRY_LOCKED' set are handled in
mv88e6xxx and other devices in this class. We have at least three
different implementations to consolidate:
1. The bridge driver, pure software forwarding. The locked entry is
dynamically created by the bridge. Packets received via the locked port
with a SA corresponding to the locked entry will be dropped, but will
refresh the entry. On the other hand, packets with a DA corresponding to
the locked entry will be forwarded as known unicast through the locked
port.
2. Hardware implementations like Spectrum that can be programmed to trap
packets that incurred an FDB miss. Like in the first case, the locked
entry is dynamically created by the bridge driver and also aged by it.
Unlike in the first case, since this entry is not present in hardware,
packets with a DA corresponding to the locked entry will be flooded as
unknown unicast.
3. Hardware implementations like mv88e6xxx that fire an interrupt upon
FDB miss. Need your help to understand how the above works there and
why. Specifically, how locked entries are represented in hardware (if at
all) and what is the significance of not installing corresponding
entries in hardware.
>
> >
> > [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 :-)
WARNING: multiple messages have this Message-ID (diff)
From: Ido Schimmel <idosch@nvidia.com>
To: netdev@kapio-technology.com
Cc: Ivan Vecera <ivecera@redhat.com>, Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Jiri Pirko <jiri@resnulli.us>,
Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, Nikolay Aleksandrov <razor@blackwall.org>,
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
Vivien Didelot <vivien.didelot@gmail.com>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
linux-kselftest@vger.kernel.org, Roopa Prabhu <roopa@nvidia.com>,
kuba@kernel.org, Vladimir Oltean <olteanv@gmail.com>,
Shuah Khan <shuah@kernel.org>,
davem@davemloft.net
Subject: Re: [Bridge] [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers
Date: Wed, 13 Jul 2022 15:39:42 +0300 [thread overview]
Message-ID: <Ys69DiAwT0Md+6ai@shredder> (raw)
In-Reply-To: <d3f674dc6b4f92f2fda3601685c78ced@kapio-technology.com>
On Wed, Jul 13, 2022 at 09:09:58AM +0200, netdev@kapio-technology.com wrote:
> On 2022-07-10 10:35, Ido Schimmel wrote:
> > 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.
>
> 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.
What are "Storm Prevention" and "zero-DPV" 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.
There is no decision that I'm aware of. I'm simply trying to understand
how FDB entries that have 'BR_FDB_ENTRY_LOCKED' set are handled in
mv88e6xxx and other devices in this class. We have at least three
different implementations to consolidate:
1. The bridge driver, pure software forwarding. The locked entry is
dynamically created by the bridge. Packets received via the locked port
with a SA corresponding to the locked entry will be dropped, but will
refresh the entry. On the other hand, packets with a DA corresponding to
the locked entry will be forwarded as known unicast through the locked
port.
2. Hardware implementations like Spectrum that can be programmed to trap
packets that incurred an FDB miss. Like in the first case, the locked
entry is dynamically created by the bridge driver and also aged by it.
Unlike in the first case, since this entry is not present in hardware,
packets with a DA corresponding to the locked entry will be flooded as
unknown unicast.
3. Hardware implementations like mv88e6xxx that fire an interrupt upon
FDB miss. Need your help to understand how the above works there and
why. Specifically, how locked entries are represented in hardware (if at
all) and what is the significance of not installing corresponding
entries in hardware.
>
> >
> > [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 :-)
next prev parent reply other threads:[~2022-07-13 12:39 UTC|newest]
Thread overview: 137+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-07 15:29 [PATCH v4 net-next 0/6] Extend locked port feature with FDB locked flag (MAC-Auth/MAB) Hans Schultz
2022-07-07 15:29 ` [Bridge] " Hans Schultz
2022-07-07 15:29 ` [PATCH v4 net-next 1/6] net: bridge: add locked entry fdb flag to extend locked port feature Hans Schultz
2022-07-07 15:29 ` [Bridge] " Hans Schultz
2022-07-10 8:20 ` Ido Schimmel
2022-07-10 8:20 ` [Bridge] " Ido Schimmel
2022-07-07 15:29 ` [PATCH v4 net-next 2/6] net: switchdev: add support for offloading of fdb locked flag Hans Schultz
2022-07-07 15:29 ` [Bridge] " Hans Schultz
2022-07-08 8:54 ` Vladimir Oltean
2022-07-08 8:54 ` [Bridge] " Vladimir Oltean
2022-08-02 8:27 ` netdev
2022-08-02 8:27 ` [Bridge] " netdev
2022-08-02 10:13 ` netdev
2022-08-02 10:13 ` [Bridge] " netdev
2022-07-07 15:29 ` [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers Hans Schultz
2022-07-07 15:29 ` [Bridge] " Hans Schultz
2022-07-08 7:12 ` kernel test robot
2022-07-08 8:49 ` Vladimir Oltean
2022-07-08 8:49 ` [Bridge] " Vladimir Oltean
2022-07-08 9:06 ` netdev
2022-07-08 9:06 ` [Bridge] " netdev
2022-07-08 9:15 ` Vladimir Oltean
2022-07-08 9:15 ` [Bridge] " Vladimir Oltean
2022-07-08 9:27 ` netdev
2022-07-08 9:27 ` [Bridge] " netdev
2022-07-08 9:50 ` netdev
2022-07-08 9:50 ` [Bridge] " netdev
2022-07-08 11:56 ` Vladimir Oltean
2022-07-08 11:56 ` [Bridge] " Vladimir Oltean
2022-07-08 12:34 ` netdev
2022-07-08 12:34 ` [Bridge] " netdev
2022-07-10 8:35 ` Ido Schimmel
2022-07-10 8:35 ` [Bridge] " Ido Schimmel
2022-07-13 7:09 ` netdev
2022-07-13 7:09 ` [Bridge] " netdev
2022-07-13 12:39 ` Ido Schimmel [this message]
2022-07-13 12:39 ` Ido Schimmel
2022-07-17 12:21 ` netdev
2022-07-17 12:21 ` [Bridge] " netdev
2022-07-17 12:57 ` Vladimir Oltean
2022-07-17 12:57 ` [Bridge] " Vladimir Oltean
2022-07-17 13:09 ` netdev
2022-07-17 13:09 ` [Bridge] " netdev
2022-07-17 13:59 ` Vladimir Oltean
2022-07-17 13:59 ` [Bridge] " Vladimir Oltean
2022-07-17 14:57 ` netdev
2022-07-17 14:57 ` [Bridge] " netdev
2022-07-17 15:08 ` Vladimir Oltean
2022-07-17 15:08 ` [Bridge] " Vladimir Oltean
2022-07-17 16:10 ` netdev
2022-07-17 16:10 ` [Bridge] " netdev
2022-07-21 11:54 ` Vladimir Oltean
2022-07-21 11:54 ` [Bridge] " Vladimir Oltean
2022-07-17 15:20 ` Ido Schimmel
2022-07-17 15:20 ` [Bridge] " Ido Schimmel
2022-07-17 15:53 ` netdev
2022-07-17 15:53 ` [Bridge] " netdev
2022-07-21 11:59 ` Vladimir Oltean
2022-07-21 11:59 ` [Bridge] " Vladimir Oltean
2022-07-21 13:27 ` Ido Schimmel
2022-07-21 13:27 ` [Bridge] " Ido Schimmel
2022-07-21 14:20 ` Vladimir Oltean
2022-07-21 14:20 ` [Bridge] " Vladimir Oltean
2022-07-24 11:10 ` Ido Schimmel
2022-07-24 11:10 ` [Bridge] " Ido Schimmel
2022-08-01 11:57 ` netdev
2022-08-01 11:57 ` [Bridge] " netdev
2022-08-01 13:14 ` netdev
2022-08-01 13:14 ` [Bridge] " netdev
2022-08-02 12:54 ` netdev
2022-08-02 12:54 ` [Bridge] " netdev
2022-08-01 15:33 ` netdev
2022-08-01 15:33 ` [Bridge] " netdev
2022-08-09 9:20 ` Ido Schimmel
2022-08-09 9:20 ` [Bridge] " Ido Schimmel
2022-08-09 20:00 ` netdev
2022-08-09 20:00 ` [Bridge] " netdev
2022-08-10 7:21 ` Ido Schimmel
2022-08-10 7:21 ` [Bridge] " Ido Schimmel
2022-08-10 8:40 ` netdev
2022-08-10 8:40 ` [Bridge] " netdev
2022-08-11 11:28 ` Ido Schimmel
2022-08-11 11:28 ` [Bridge] " Ido Schimmel
2022-08-12 15:33 ` netdev
2022-08-12 15:33 ` [Bridge] " netdev
2022-08-16 7:51 ` netdev
2022-08-16 7:51 ` [Bridge] " netdev
2022-08-17 6:21 ` Ido Schimmel
2022-08-17 6:21 ` [Bridge] " Ido Schimmel
2022-07-21 11:51 ` Vladimir Oltean
2022-07-21 11:51 ` [Bridge] " Vladimir Oltean
2022-07-08 20:39 ` kernel test robot
2022-07-07 15:29 ` [PATCH v4 net-next 4/6] net: dsa: mv88e6xxx: allow reading FID when handling ATU violations Hans Schultz
2022-07-07 15:29 ` [Bridge] " Hans Schultz
2022-07-07 15:29 ` [PATCH v4 net-next 5/6] net: dsa: mv88e6xxx: mac-auth/MAB implementation Hans Schultz
2022-07-07 15:29 ` [Bridge] " Hans Schultz
2022-07-08 9:46 ` kernel test robot
2022-07-17 0:47 ` Vladimir Oltean
2022-07-17 0:47 ` [Bridge] " Vladimir Oltean
2022-07-17 12:34 ` netdev
2022-07-17 12:34 ` [Bridge] " netdev
2022-07-21 12:04 ` Vladimir Oltean
2022-07-21 12:04 ` [Bridge] " Vladimir Oltean
2022-08-19 8:28 ` netdev
2022-08-19 8:28 ` [Bridge] " netdev
2022-07-07 15:29 ` [PATCH v4 net-next 6/6] selftests: forwarding: add test of MAC-Auth Bypass to locked port tests Hans Schultz
2022-07-07 15:29 ` [Bridge] " Hans Schultz
2022-07-10 7:29 ` Ido Schimmel
2022-07-10 7:29 ` [Bridge] " Ido Schimmel
2022-07-12 12:28 ` netdev
2022-07-12 12:28 ` [Bridge] " netdev
2022-07-08 1:00 ` [PATCH v4 net-next 0/6] Extend locked port feature with FDB locked flag (MAC-Auth/MAB) Jakub Kicinski
2022-07-08 1:00 ` [Bridge] " Jakub Kicinski
2022-08-11 5:09 ` Benjamin Poirier
2022-08-11 5:09 ` [Bridge] " Benjamin Poirier
-- strict thread matches above, loose matches on Subject: below --
2022-08-12 12:29 [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers netdev
2022-08-14 14:55 ` Ido Schimmel
2022-08-19 9:51 ` netdev
2022-08-21 7:08 ` Ido Schimmel
2022-08-21 13:43 ` netdev
2022-08-22 5:40 ` Ido Schimmel
2022-08-22 7:49 ` netdev
2022-08-23 6:48 ` Ido Schimmel
2022-08-23 7:13 ` netdev
2022-08-23 7:24 ` Ido Schimmel
2022-08-23 7:37 ` netdev
2022-08-23 12:36 ` Ido Schimmel
2022-08-24 7:07 ` netdev
2022-08-23 11:41 ` netdev
2022-08-25 9:36 ` Ido Schimmel
2022-08-25 10:28 ` netdev
2022-08-25 15:14 ` netdev
2022-08-24 20:29 ` netdev
2022-08-25 9:23 ` Ido Schimmel
2022-08-25 10:27 ` netdev
2022-08-25 11:58 ` Ido Schimmel
2022-08-25 13:41 ` netdev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Ys69DiAwT0Md+6ai@shredder \
--to=idosch@nvidia.com \
--cc=andrew@lunn.ch \
--cc=bridge@lists.linux-foundation.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=ivecera@redhat.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=netdev@kapio-technology.com \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=roopa@nvidia.com \
--cc=shuah@kernel.org \
--cc=vivien.didelot@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.