From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C242DC43334 for ; Wed, 13 Jul 2022 07:10:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234517AbiGMHKP (ORCPT ); Wed, 13 Jul 2022 03:10:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35070 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234576AbiGMHKE (ORCPT ); Wed, 13 Jul 2022 03:10:04 -0400 Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CEEC212097; Wed, 13 Jul 2022 00:10:01 -0700 (PDT) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 68F651886A00; Wed, 13 Jul 2022 07:09:59 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id 618F625032B7; Wed, 13 Jul 2022 07:09:59 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id 4745DA1E0083; Wed, 13 Jul 2022 07:09:59 +0000 (UTC) X-Screener-Id: 413d8c6ce5bf6eab4824d0abaab02863e8e3f662 MIME-Version: 1.0 Date: Wed, 13 Jul 2022 09:09:58 +0200 From: netdev@kapio-technology.com To: Ido Schimmel Cc: Vladimir Oltean , davem@davemloft.net, kuba@kernel.org, netdev@vger.kernel.org, Andrew Lunn , Vivien Didelot , Florian Fainelli , Eric Dumazet , Paolo Abeni , Jiri Pirko , Ivan Vecera , Roopa Prabhu , Nikolay Aleksandrov , Shuah Khan , Daniel Borkmann , 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 In-Reply-To: References: <20220707152930.1789437-1-netdev@kapio-technology.com> <20220707152930.1789437-4-netdev@kapio-technology.com> <20220708084904.33otb6x256huddps@skbuf> <20220708091550.2qcu3tyqkhgiudjg@skbuf> <20220708115624.rrjzjtidlhcqczjv@skbuf> <723e2995314b41ff323272536ef27341@kapio-technology.com> User-Agent: Gigahost Webmail Message-ID: X-Sender: netdev@kapio-technology.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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/ > >> >> > >> > 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 :-) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2457B84145 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C77668411D MIME-Version: 1.0 Date: Wed, 13 Jul 2022 09:09:58 +0200 From: netdev@kapio-technology.com In-Reply-To: References: <20220707152930.1789437-1-netdev@kapio-technology.com> <20220707152930.1789437-4-netdev@kapio-technology.com> <20220708084904.33otb6x256huddps@skbuf> <20220708091550.2qcu3tyqkhgiudjg@skbuf> <20220708115624.rrjzjtidlhcqczjv@skbuf> <723e2995314b41ff323272536ef27341@kapio-technology.com> Message-ID: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Bridge] [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ido Schimmel Cc: Ivan Vecera , Andrew Lunn , Florian Fainelli , Jiri Pirko , Daniel Borkmann , netdev@vger.kernel.org, Nikolay Aleksandrov , bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org, Vivien Didelot , Eric Dumazet , Paolo Abeni , linux-kselftest@vger.kernel.org, Roopa Prabhu , kuba@kernel.org, Vladimir Oltean , Shuah Khan , davem@davemloft.net 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. 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/ > >> >> > >> > 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 :-)