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: Tue, 23 Aug 2022 09:48:17 +0300 [thread overview] Message-ID: <YwR4MQ2xOMlvKocw@shredder> (raw) In-Reply-To: <c2822d6dd66a1239ff8b7bfd06019008@kapio-technology.com> On Mon, Aug 22, 2022 at 09:49:28AM +0200, netdev@kapio-technology.com wrote: > On 2022-08-22 07:40, Ido Schimmel wrote: > > On Sun, Aug 21, 2022 at 03:43:04PM +0200, netdev@kapio-technology.com > > wrote: > > > > I personally think that the mv88e6xxx semantics are very weird (e.g., no > > roaming, traffic blackhole) and I don't want them to determine how the > > feature works in the pure software bridge or other hardware > > implementations. On the other hand, I understand your constraints and I > > don't want to create a situation where user space is unable to > > understand how the data path works from the bridge FDB dump with > > mv88e6xxx. > > > > My suggestion is to have mv88e6xxx report the "locked" entry to the > > bridge driver with additional flags that describe its behavior in terms > > of roaming, ageing and forwarding. > > > > In terms of roaming, since in mv88e6xxx the entry can't roam you should > > report the entry with the "sticky" flag. > > As I am not familiar with roaming in this context, I need to know how the SW > bridge should behave in this case. I think I wasn't clear enough. The idea is to make the bridge compatible with mv88e6xxx in a way that is discoverable by user space by having mv88e6xxx add the locked entry with flags that describe the hardware behavior. Therefore, it's not a matter of "how the SW bridge should behave", but having it behave in a way that matches the offloaded data path. From what I was able to understand from you, the "locked" entry cannot roam at all in mv88e6xxx, which can be described by the "sticky" flag. > In this I am assuming that roaming is regarding unauthorized entries. Yes, talking about "locked" entries that are notified by mv88e6xxx to the bridge. > In this case, is the roaming only between locked ports or does the > roaming include that the entry can move to a unlocked port, resulting > in the locked flag getting removed? Any two ports. If the "locked" entry in mv88e6xxx cannot move once installed, then the "sticky" flag accurately describes it. > > > In terms of ageing, since > > mv88e6xxx is the one doing the ageing and not the bridge driver, report > > the entry with the "extern_learn" flag. > > Just for the record, I see that entries coming from the driver to the bridge > will always have the "extern learn" flag set as can be seen from the > SWITCHDEV_FDB_ADD_TO_BRIDGE events handling in br_switchdev_event() in br.c, > which I think is the correct behavior. Yes. > > > In terms of forwarding, in > > mv88e6xxx the entry discards all matching packets. We can introduce a > > new FDB flag that instructs the entry to silently discard all matching > > packets. Like we have with blackhole routes and nexthops. > > Any suggestions to the name of this flag? I'm not good at naming, but "blackhole" is at least consistent with what we already have for routes and nexthop objects. > > > > > I believe that the above suggestion allows you to fully describe how > > these entries work in mv88e6xxx while keeping the bridge driver in sync > > with complete visibility towards user space. > > > > It also frees the pure software implementation from the constraints of > > mv88e6xxx, allowing "locked" entries to behave like any other > > dynamically learned entries modulo the fact that they cannot "unlock" a > > locked port. > > > > Yes, it does mean that user space will get a bit different behavior with > > mv88e6xxx compared to a pure software solution, but a) It's only the > > corner cases that act a bit differently. As a whole, the feature works > > largely the same. b) User space has complete visibility to understand > > the behavior of the offloaded data path. > > > > > > > > > I will change it in iproute2 to: > > > bridge link set dev DEV mab on|off > > > > And s/BR_PORT_MACAUTH/BR_PORT_MAB/ ? > > Sure, I will do that. :-) Thanks
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: Tue, 23 Aug 2022 09:48:17 +0300 [thread overview] Message-ID: <YwR4MQ2xOMlvKocw@shredder> (raw) In-Reply-To: <c2822d6dd66a1239ff8b7bfd06019008@kapio-technology.com> On Mon, Aug 22, 2022 at 09:49:28AM +0200, netdev@kapio-technology.com wrote: > On 2022-08-22 07:40, Ido Schimmel wrote: > > On Sun, Aug 21, 2022 at 03:43:04PM +0200, netdev@kapio-technology.com > > wrote: > > > > I personally think that the mv88e6xxx semantics are very weird (e.g., no > > roaming, traffic blackhole) and I don't want them to determine how the > > feature works in the pure software bridge or other hardware > > implementations. On the other hand, I understand your constraints and I > > don't want to create a situation where user space is unable to > > understand how the data path works from the bridge FDB dump with > > mv88e6xxx. > > > > My suggestion is to have mv88e6xxx report the "locked" entry to the > > bridge driver with additional flags that describe its behavior in terms > > of roaming, ageing and forwarding. > > > > In terms of roaming, since in mv88e6xxx the entry can't roam you should > > report the entry with the "sticky" flag. > > As I am not familiar with roaming in this context, I need to know how the SW > bridge should behave in this case. I think I wasn't clear enough. The idea is to make the bridge compatible with mv88e6xxx in a way that is discoverable by user space by having mv88e6xxx add the locked entry with flags that describe the hardware behavior. Therefore, it's not a matter of "how the SW bridge should behave", but having it behave in a way that matches the offloaded data path. From what I was able to understand from you, the "locked" entry cannot roam at all in mv88e6xxx, which can be described by the "sticky" flag. > In this I am assuming that roaming is regarding unauthorized entries. Yes, talking about "locked" entries that are notified by mv88e6xxx to the bridge. > In this case, is the roaming only between locked ports or does the > roaming include that the entry can move to a unlocked port, resulting > in the locked flag getting removed? Any two ports. If the "locked" entry in mv88e6xxx cannot move once installed, then the "sticky" flag accurately describes it. > > > In terms of ageing, since > > mv88e6xxx is the one doing the ageing and not the bridge driver, report > > the entry with the "extern_learn" flag. > > Just for the record, I see that entries coming from the driver to the bridge > will always have the "extern learn" flag set as can be seen from the > SWITCHDEV_FDB_ADD_TO_BRIDGE events handling in br_switchdev_event() in br.c, > which I think is the correct behavior. Yes. > > > In terms of forwarding, in > > mv88e6xxx the entry discards all matching packets. We can introduce a > > new FDB flag that instructs the entry to silently discard all matching > > packets. Like we have with blackhole routes and nexthops. > > Any suggestions to the name of this flag? I'm not good at naming, but "blackhole" is at least consistent with what we already have for routes and nexthop objects. > > > > > I believe that the above suggestion allows you to fully describe how > > these entries work in mv88e6xxx while keeping the bridge driver in sync > > with complete visibility towards user space. > > > > It also frees the pure software implementation from the constraints of > > mv88e6xxx, allowing "locked" entries to behave like any other > > dynamically learned entries modulo the fact that they cannot "unlock" a > > locked port. > > > > Yes, it does mean that user space will get a bit different behavior with > > mv88e6xxx compared to a pure software solution, but a) It's only the > > corner cases that act a bit differently. As a whole, the feature works > > largely the same. b) User space has complete visibility to understand > > the behavior of the offloaded data path. > > > > > > > > > I will change it in iproute2 to: > > > bridge link set dev DEV mab on|off > > > > And s/BR_PORT_MACAUTH/BR_PORT_MAB/ ? > > Sure, I will do that. :-) Thanks
next prev parent reply other threads:[~2022-08-23 6:48 UTC|newest] Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-08-12 12:29 [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers netdev 2022-08-12 12:29 ` [Bridge] " netdev 2022-08-14 14:55 ` Ido Schimmel 2022-08-14 14:55 ` [Bridge] " Ido Schimmel 2022-08-19 9:51 ` netdev 2022-08-19 9:51 ` [Bridge] " netdev 2022-08-21 7:08 ` Ido Schimmel 2022-08-21 7:08 ` [Bridge] " Ido Schimmel 2022-08-21 13:43 ` netdev 2022-08-21 13:43 ` [Bridge] " netdev 2022-08-22 5:40 ` Ido Schimmel 2022-08-22 5:40 ` [Bridge] " Ido Schimmel 2022-08-22 7:49 ` netdev 2022-08-22 7:49 ` [Bridge] " netdev 2022-08-23 6:48 ` Ido Schimmel [this message] 2022-08-23 6:48 ` Ido Schimmel 2022-08-23 7:13 ` netdev 2022-08-23 7:13 ` [Bridge] " netdev 2022-08-23 7:24 ` Ido Schimmel 2022-08-23 7:24 ` [Bridge] " Ido Schimmel 2022-08-23 7:37 ` netdev 2022-08-23 7:37 ` [Bridge] " netdev 2022-08-23 12:36 ` Ido Schimmel 2022-08-23 12:36 ` [Bridge] " Ido Schimmel 2022-08-24 7:07 ` netdev 2022-08-24 7:07 ` [Bridge] " netdev 2022-08-23 11:41 ` netdev 2022-08-23 11:41 ` [Bridge] " netdev 2022-08-25 9:36 ` Ido Schimmel 2022-08-25 9:36 ` [Bridge] " Ido Schimmel 2022-08-25 10:28 ` netdev 2022-08-25 10:28 ` [Bridge] " netdev 2022-08-25 15:14 ` netdev 2022-08-25 15:14 ` [Bridge] " netdev 2022-08-24 20:29 ` netdev 2022-08-24 20:29 ` [Bridge] " netdev 2022-08-25 9:23 ` Ido Schimmel 2022-08-25 9:23 ` [Bridge] " Ido Schimmel 2022-08-25 10:27 ` netdev 2022-08-25 10:27 ` [Bridge] " netdev 2022-08-25 11:58 ` Ido Schimmel 2022-08-25 11:58 ` [Bridge] " Ido Schimmel 2022-08-25 13:41 ` netdev 2022-08-25 13:41 ` [Bridge] " netdev -- strict thread matches above, loose matches on Subject: below -- 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 ` [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers Hans Schultz 2022-07-08 7:12 ` kernel test robot 2022-07-08 8:49 ` Vladimir Oltean 2022-07-08 9:06 ` netdev 2022-07-08 9:15 ` Vladimir Oltean 2022-07-08 9:27 ` netdev 2022-07-08 9:50 ` netdev 2022-07-08 11:56 ` Vladimir Oltean 2022-07-08 12:34 ` netdev 2022-07-10 8:35 ` Ido Schimmel 2022-07-13 7:09 ` netdev 2022-07-13 12:39 ` Ido Schimmel 2022-07-17 12:21 ` netdev 2022-07-17 12:57 ` Vladimir Oltean 2022-07-17 13:09 ` netdev 2022-07-17 13:59 ` Vladimir Oltean 2022-07-17 14:57 ` netdev 2022-07-17 15:08 ` Vladimir Oltean 2022-07-17 16:10 ` netdev 2022-07-21 11:54 ` Vladimir Oltean 2022-07-17 15:20 ` Ido Schimmel 2022-07-17 15:53 ` netdev 2022-07-21 11:59 ` Vladimir Oltean 2022-07-21 13:27 ` Ido Schimmel 2022-07-21 14:20 ` Vladimir Oltean 2022-07-24 11:10 ` Ido Schimmel 2022-08-01 11:57 ` netdev 2022-08-01 13:14 ` netdev 2022-08-02 12:54 ` netdev 2022-08-01 15:33 ` netdev 2022-08-09 9:20 ` Ido Schimmel 2022-08-09 20:00 ` netdev 2022-08-10 7:21 ` Ido Schimmel 2022-08-10 8:40 ` netdev 2022-08-11 11:28 ` Ido Schimmel 2022-08-12 15:33 ` netdev 2022-08-16 7:51 ` netdev 2022-08-17 6:21 ` Ido Schimmel 2022-07-21 11:51 ` Vladimir Oltean 2022-07-08 20:39 ` kernel test robot
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=YwR4MQ2xOMlvKocw@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: linkBe 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.