Message ID | 20230117185714.3058453-2-netdev@kapio-technology.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp1975792wrn; Tue, 17 Jan 2023 12:53:33 -0800 (PST) X-Google-Smtp-Source: AMrXdXv1ermySj2tBVw3tZ+CQPp2vVkvqB7DA8Yfujqa1V7AT5Zpu6qB7dYEtAjfRG1ncV60rU2/ X-Received: by 2002:a05:6a20:a012:b0:a3:5864:e0c5 with SMTP id p18-20020a056a20a01200b000a35864e0c5mr5343239pzj.9.1673988812801; Tue, 17 Jan 2023 12:53:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673988812; cv=none; d=google.com; s=arc-20160816; b=QTnZXxj3Xwg+DnpmfELAneCZXRjGo/u74v4WrdhWfNAUGCx8Pn0cgtjl04KbdikBwa bXYQ3OqGifg5syd65uFgI5UFwP+vwUcgYayrPxH+fjvyq+1XK09qyoXSkRieo5MQn533 RXvCp1r0tc6Mj/JatxThtgMkxpHMXamSlzuOCN/dyuCCkgg235iH7vopNCRS1/iEhDWc 52Wl8rGCVzfgAcJkGH8IeaxMYGT2f6AELE+0cATFamldB7S0I3H/tg6zhrg0gSgx8sbZ Y5p+tk3ZpNWzxRDUS2CfXRwBxYFQcai5jt7P7LM/RRVox+ZttnK51xcLIWwSBNK0iT+8 tRgA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:organization :mime-version:references:in-reply-to:message-id:date:subject:cc:to :from; bh=oCxlfN+5O4LHXKt5ZOG1T60DX1xFjpOlUhTi34G3tNQ=; b=uyOg2zw9ORQ/cnWgYLNfpjhcMJIMyGCvydBNBnUbHYwhVbbCE5wkaDZ1UbEUuRU/b2 NU/BVQpUab5xMalQ4zirG9yzV6gLl7Xc+sJNp6Y8iv2WkI6TTWnTXQwIyT6UA7XZKaaU x1iN9T2L9Kh0Z17jzp+lV4wAiv0FvvDG/wa4nvF9UvjD8QPiB3zkCDidoSQKeSzFV82H w+DnA7zy+SuIkKjfrgRdLP1tB5iw8lo7jfvZZEnMeltd/lNi35+JLxxbkx0nla7FAsiE LGOGGZzhlFd4AfO8nBpsdQPeImQlkZv1aCQCZm52gCurf0V0+xgwE9jUAqzJXurjhx9U H8Zw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g11-20020a63520b000000b00476f2b0b330si33202926pgb.700.2023.01.17.12.53.17; Tue, 17 Jan 2023 12:53:32 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232187AbjAQUwa (ORCPT <rfc822;pfffrao@gmail.com> + 99 others); Tue, 17 Jan 2023 15:52:30 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59132 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235257AbjAQUtW (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 17 Jan 2023 15:49:22 -0500 Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9314F47423; Tue, 17 Jan 2023 11:25:07 -0800 (PST) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 0884118835F8; Tue, 17 Jan 2023 18:59:13 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id EE2C8250007B; Tue, 17 Jan 2023 18:59:12 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id E5B499EC000B; Tue, 17 Jan 2023 18:59:12 +0000 (UTC) X-Screener-Id: 413d8c6ce5bf6eab4824d0abaab02863e8e3f662 Received: from fujitsu.vestervang (2-104-116-184-cable.dk.customer.tdc.net [2.104.116.184]) by smtp.gigahost.dk (Postfix) with ESMTPSA id 48D9991201E4; Tue, 17 Jan 2023 18:59:12 +0000 (UTC) From: "Hans J. Schultz" <netdev@kapio-technology.com> To: davem@davemloft.net, kuba@kernel.org Cc: netdev@vger.kernel.org, "Hans J. Schultz" <netdev@kapio-technology.com>, Florian Fainelli <f.fainelli@gmail.com>, Andrew Lunn <andrew@lunn.ch>, Vladimir Oltean <olteanv@gmail.com>, Eric Dumazet <edumazet@google.com>, Paolo Abeni <pabeni@redhat.com>, Kurt Kanzenbach <kurt@linutronix.de>, Hauke Mehrtens <hauke@hauke-m.de>, Woojung Huh <woojung.huh@microchip.com>, UNGLinuxDriver@microchip.com (maintainer:MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER), Sean Wang <sean.wang@mediatek.com>, Landen Chao <Landen.Chao@mediatek.com>, DENG Qingfang <dqfext@gmail.com>, Matthias Brugger <matthias.bgg@gmail.com>, Claudiu Manoil <claudiu.manoil@nxp.com>, Alexandre Belloni <alexandre.belloni@bootlin.com>, =?utf-8?b?Q2zDqW1lbnQg?= =?utf-8?b?TMOpZ2Vy?= <clement.leger@bootlin.com>, Jiri Pirko <jiri@resnulli.us>, Ivan Vecera <ivecera@redhat.com>, Roopa Prabhu <roopa@nvidia.com>, Nikolay Aleksandrov <razor@blackwall.org>, Russell King <linux@armlinux.org.uk>, Christian Marangi <ansuelsmth@gmail.com>, linux-kernel@vger.kernel.org (open list), linux-arm-kernel@lists.infradead.org (moderated list:ARM/Mediatek SoC support), linux-mediatek@lists.infradead.org (moderated list:ARM/Mediatek SoC support), linux-renesas-soc@vger.kernel.org (open list:RENESAS RZ/N1 A5PSW SWITCH DRIVER), bridge@lists.linux-foundation.org (moderated list:ETHERNET BRIDGE) Subject: [RFC PATCH net-next 1/5] net: bridge: add dynamic flag to switchdev notifier Date: Tue, 17 Jan 2023 19:57:10 +0100 Message-Id: <20230117185714.3058453-2-netdev@kapio-technology.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230117185714.3058453-1-netdev@kapio-technology.com> References: <20230117185714.3058453-1-netdev@kapio-technology.com> MIME-Version: 1.0 Organization: Westermo Network Technologies AB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755304492896452166?= X-GMAIL-MSGID: =?utf-8?q?1755304492896452166?= |
Series |
ATU and FDB synchronization on locked ports
|
|
Commit Message
Hans Schultz
Jan. 17, 2023, 6:57 p.m. UTC
To be able to add dynamic FDB entries to drivers from userspace, the
dynamic flag must be added when sending RTM_NEWNEIGH events down.
Signed-off-by: Hans J. Schultz <netdev@kapio-technology.com>
---
include/net/switchdev.h | 1 +
net/bridge/br_switchdev.c | 1 +
2 files changed, 2 insertions(+)
Comments
On Tue, Jan 17, 2023 at 07:57:10PM +0100, Hans J. Schultz wrote: > To be able to add dynamic FDB entries to drivers from userspace, the > dynamic flag must be added when sending RTM_NEWNEIGH events down. > > Signed-off-by: Hans J. Schultz <netdev@kapio-technology.com> > --- > include/net/switchdev.h | 1 + > net/bridge/br_switchdev.c | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/include/net/switchdev.h b/include/net/switchdev.h > index ca0312b78294..aaf918d4ba67 100644 > --- a/include/net/switchdev.h > +++ b/include/net/switchdev.h > @@ -249,6 +249,7 @@ struct switchdev_notifier_fdb_info { > u8 added_by_user:1, > is_local:1, > locked:1, > + is_dyn:1, > offloaded:1; > }; > > diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c > index 7eb6fd5bb917..60c05a00a1df 100644 > --- a/net/bridge/br_switchdev.c > +++ b/net/bridge/br_switchdev.c > @@ -136,6 +136,7 @@ static void br_switchdev_fdb_populate(struct net_bridge *br, > item->added_by_user = test_bit(BR_FDB_ADDED_BY_USER, &fdb->flags); > item->offloaded = test_bit(BR_FDB_OFFLOADED, &fdb->flags); > item->is_local = test_bit(BR_FDB_LOCAL, &fdb->flags); > + item->is_dyn = !test_bit(BR_FDB_STATIC, &fdb->flags); Why reverse logic? Why not just name this "is_static" and leave any further interpretations up to the consumer? > item->locked = false; > item->info.dev = (!p || item->is_local) ? br->dev : p->dev; > item->info.ctx = ctx; > -- > 2.34.1 >
On 2023-01-18 00:08, Vladimir Oltean wrote: > On Tue, Jan 17, 2023 at 07:57:10PM +0100, Hans J. Schultz wrote: >> To be able to add dynamic FDB entries to drivers from userspace, the >> dynamic flag must be added when sending RTM_NEWNEIGH events down. >> >> Signed-off-by: Hans J. Schultz <netdev@kapio-technology.com> >> --- >> include/net/switchdev.h | 1 + >> net/bridge/br_switchdev.c | 1 + >> 2 files changed, 2 insertions(+) >> >> diff --git a/include/net/switchdev.h b/include/net/switchdev.h >> index ca0312b78294..aaf918d4ba67 100644 >> --- a/include/net/switchdev.h >> +++ b/include/net/switchdev.h >> @@ -249,6 +249,7 @@ struct switchdev_notifier_fdb_info { >> u8 added_by_user:1, >> is_local:1, >> locked:1, >> + is_dyn:1, >> offloaded:1; >> }; >> >> diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c >> index 7eb6fd5bb917..60c05a00a1df 100644 >> --- a/net/bridge/br_switchdev.c >> +++ b/net/bridge/br_switchdev.c >> @@ -136,6 +136,7 @@ static void br_switchdev_fdb_populate(struct >> net_bridge *br, >> item->added_by_user = test_bit(BR_FDB_ADDED_BY_USER, &fdb->flags); >> item->offloaded = test_bit(BR_FDB_OFFLOADED, &fdb->flags); >> item->is_local = test_bit(BR_FDB_LOCAL, &fdb->flags); >> + item->is_dyn = !test_bit(BR_FDB_STATIC, &fdb->flags); > > Why reverse logic? Why not just name this "is_static" and leave any > further interpretations up to the consumer? > My reasoning for this is that the common case is to have static entries, thus is_dyn=false, so whenever someone uses a switchdev_notifier_fdb_info struct the common case does not need to be entered. Otherwise it might also break something when someone uses this struct and if it was 'is_static' and they forget to code is_static=true they will get dynamic entries without wanting it and it can be hard to find such an error. >> item->locked = false; >> item->info.dev = (!p || item->is_local) ? br->dev : p->dev; >> item->info.ctx = ctx; >> -- >> 2.34.1 >>
On Wed, Jan 18, 2023 at 11:14:00PM +0100, netdev@kapio-technology.com wrote: > > > + item->is_dyn = !test_bit(BR_FDB_STATIC, &fdb->flags); > > > > Why reverse logic? Why not just name this "is_static" and leave any > > further interpretations up to the consumer? > > My reasoning for this is that the common case is to have static entries, > thus is_dyn=false, so whenever someone uses a switchdev_notifier_fdb_info > struct the common case does not need to be entered. > Otherwise it might also break something when someone uses this struct and if > it was 'is_static' and they forget to code is_static=true they will get > dynamic entries without wanting it and it can be hard to find such an error. I'll leave it up to bridge maintainers if this is preferable to patching all callers of SWITCHDEV_FDB_ADD_TO_BRIDGE such that they set is_static=true.
On Thu, Jan 19, 2023 at 11:33:58AM +0200, Vladimir Oltean wrote: > On Wed, Jan 18, 2023 at 11:14:00PM +0100, netdev@kapio-technology.com wrote: > > > > + item->is_dyn = !test_bit(BR_FDB_STATIC, &fdb->flags); > > > > > > Why reverse logic? Why not just name this "is_static" and leave any > > > further interpretations up to the consumer? > > > > My reasoning for this is that the common case is to have static entries, > > thus is_dyn=false, so whenever someone uses a switchdev_notifier_fdb_info > > struct the common case does not need to be entered. > > Otherwise it might also break something when someone uses this struct and if > > it was 'is_static' and they forget to code is_static=true they will get > > dynamic entries without wanting it and it can be hard to find such an error. > > I'll leave it up to bridge maintainers if this is preferable to patching > all callers of SWITCHDEV_FDB_ADD_TO_BRIDGE such that they set is_static=true. Actually, why would you assume that all users of SWITCHDEV_FDB_ADD_TO_BRIDGE want to add static FDB entries? You can't avoid inspecting the code and making sure that the is_dyn/is_static flag is set correctly either way.
On 2023-01-19 14:40, Vladimir Oltean wrote: > On Thu, Jan 19, 2023 at 11:33:58AM +0200, Vladimir Oltean wrote: >> On Wed, Jan 18, 2023 at 11:14:00PM +0100, netdev@kapio-technology.com >> wrote: >> > > > + item->is_dyn = !test_bit(BR_FDB_STATIC, &fdb->flags); >> > > >> > > Why reverse logic? Why not just name this "is_static" and leave any >> > > further interpretations up to the consumer? >> > >> > My reasoning for this is that the common case is to have static entries, >> > thus is_dyn=false, so whenever someone uses a switchdev_notifier_fdb_info >> > struct the common case does not need to be entered. >> > Otherwise it might also break something when someone uses this struct and if >> > it was 'is_static' and they forget to code is_static=true they will get >> > dynamic entries without wanting it and it can be hard to find such an error. >> >> I'll leave it up to bridge maintainers if this is preferable to >> patching >> all callers of SWITCHDEV_FDB_ADD_TO_BRIDGE such that they set >> is_static=true. > > Actually, why would you assume that all users of > SWITCHDEV_FDB_ADD_TO_BRIDGE > want to add static FDB entries? You can't avoid inspecting the code and > making sure that the is_dyn/is_static flag is set correctly either way. Well, up until this patch set there is no option, besides entries from SWITCHDEV_FDB_ADD_TO_BRIDGE events will get the external learned flag set, so they will not be aged by the bridge, and so dynamic entries that way don't make much sense I think. Is that not right?
diff --git a/include/net/switchdev.h b/include/net/switchdev.h index ca0312b78294..aaf918d4ba67 100644 --- a/include/net/switchdev.h +++ b/include/net/switchdev.h @@ -249,6 +249,7 @@ struct switchdev_notifier_fdb_info { u8 added_by_user:1, is_local:1, locked:1, + is_dyn:1, offloaded:1; }; diff --git a/net/bridge/br_switchdev.c b/net/bridge/br_switchdev.c index 7eb6fd5bb917..60c05a00a1df 100644 --- a/net/bridge/br_switchdev.c +++ b/net/bridge/br_switchdev.c @@ -136,6 +136,7 @@ static void br_switchdev_fdb_populate(struct net_bridge *br, item->added_by_user = test_bit(BR_FDB_ADDED_BY_USER, &fdb->flags); item->offloaded = test_bit(BR_FDB_OFFLOADED, &fdb->flags); item->is_local = test_bit(BR_FDB_LOCAL, &fdb->flags); + item->is_dyn = !test_bit(BR_FDB_STATIC, &fdb->flags); item->locked = false; item->info.dev = (!p || item->is_local) ? br->dev : p->dev; item->info.ctx = ctx;