Message ID | 20230130173429.3577450-5-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 s9csp2308619wrn; Mon, 30 Jan 2023 09:40:06 -0800 (PST) X-Google-Smtp-Source: AMrXdXtEAPKWX0VEk0NYrKUYBJgq6/6fgzP6UEzuPCRhFubF/ZJwQcT/V89tY0koEws9goQGbDfF X-Received: by 2002:a05:6402:501a:b0:47e:bdb8:9133 with SMTP id p26-20020a056402501a00b0047ebdb89133mr63506322eda.38.1675100406242; Mon, 30 Jan 2023 09:40:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675100406; cv=none; d=google.com; s=arc-20160816; b=p4+bm7XZJoYEG+BtQ6qTc6OlmjUYjeRS6jo8FibgyLKPOi2FkmR8XV1MEXwu9BhR+c Y1iYxDvQ1MxVAiUpDQ+/rO3Ekwfw7H7ioEIr30xU/axdrYuBIpTZ/2UWXM8nr/p6MhkY +ubMXV9ZPEPQBaEN196gi7kGkZzCAQ/n4dILHJ/jVsgiQfjcR93Y6VYhJlLf6UBHFJPw 2naQ4/uJc9r4lsdHamrLGZr+x4zl+4YWKOJV2ndmf9q5YJnAoIEcuKKoulQETKExH0xz Pwkup0a7OfPOGBfqPOqpdmX8nt3Y5qC5j2hEtp6HX6uLW08KiLRR/yJMfKMrjowXk4SG 0sBQ== 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=kr7hOd6c8hT924R9Kmj87tFZQb5RQTTidtVqB6Z9AKQ=; b=HqFvYZJ4HQpWePJFKlYk3IAjlZoKZxLDuMoG60H+vg92ySFUjB3rqq4eNaYoaFAZVs Zs49+XS+WA/YH/8ZjVWPDt0roZltw1RA/5HMQvnkMQZ72qYoDEZnldn2c9O0SUK1Tb0r H1wu4zbZ/0fM92058+WcXXqOiSh+yDiIERgrofeT+Z8L0UELBmHNpjU9qCiE1vSWE4Ds B5+4IKYYWl40/BwBo86SYtTl+rLx/Z2dDzHg1UbSaUV6H42HxHMKlhDG79/VPNeFLGea mzvY/fO3DySxAq6SxTbV1BIVLNQhDtlPgvDJ/nevXc+xhwklkDqOPxkVxClmarO5Copz Mj2w== 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 g19-20020aa7c853000000b0046bb35e06e6si12417577edt.149.2023.01.30.09.39.42; Mon, 30 Jan 2023 09:40:06 -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 S237887AbjA3RhH (ORCPT <rfc822;n2h9z4@gmail.com> + 99 others); Mon, 30 Jan 2023 12:37:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236479AbjA3Rg0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 30 Jan 2023 12:36:26 -0500 Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A668B39CCB; Mon, 30 Jan 2023 09:36:24 -0800 (PST) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 286F11883875; Mon, 30 Jan 2023 17:36:23 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id 1C58E250007B; Mon, 30 Jan 2023 17:36:23 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id 0E6B29B403E6; Mon, 30 Jan 2023 17:36:22 +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 27C7991201E4; Mon, 30 Jan 2023 17:36:22 +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: [PATCH net-next 4/5] net: bridge: ensure FDB offloaded flag is handled as needed Date: Mon, 30 Jan 2023 18:34:28 +0100 Message-Id: <20230130173429.3577450-5-netdev@kapio-technology.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230130173429.3577450-1-netdev@kapio-technology.com> References: <20230130173429.3577450-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?1756470083564758845?= X-GMAIL-MSGID: =?utf-8?q?1756470083564758845?= |
Series |
ATU and FDB synchronization on locked ports
|
|
Commit Message
Hans Schultz
Jan. 30, 2023, 5:34 p.m. UTC
Since user added entries in the bridge FDB will get the BR_FDB_OFFLOADED
flag set, we do not want the bridge to age those entries and we want the
entries to be deleted in the bridge upon an SWITCHDEV_FDB_DEL_TO_BRIDGE
event.
Signed-off-by: Hans J. Schultz <netdev@kapio-technology.com>
---
net/bridge/br_fdb.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Comments
On Mon, Jan 30, 2023 at 06:34:28PM +0100, Hans J. Schultz wrote: > Since user added entries in the bridge FDB will get the BR_FDB_OFFLOADED > flag set, we do not want the bridge to age those entries and we want the > entries to be deleted in the bridge upon an SWITCHDEV_FDB_DEL_TO_BRIDGE > event. > > Signed-off-by: Hans J. Schultz <netdev@kapio-technology.com> > --- > net/bridge/br_fdb.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c > index e69a872bfc1d..b0c23a72bc76 100644 > --- a/net/bridge/br_fdb.c > +++ b/net/bridge/br_fdb.c > @@ -537,6 +537,7 @@ void br_fdb_cleanup(struct work_struct *work) > unsigned long this_timer = f->updated + delay; > > if (test_bit(BR_FDB_STATIC, &f->flags) || > + test_bit(BR_FDB_OFFLOADED, &f->flags) || > test_bit(BR_FDB_ADDED_BY_EXT_LEARN, &f->flags)) { > if (test_bit(BR_FDB_NOTIFY, &f->flags)) { > if (time_after(this_timer, now)) Looks correct > @@ -1465,7 +1466,9 @@ int br_fdb_external_learn_del(struct net_bridge *br, struct net_bridge_port *p, > spin_lock_bh(&br->hash_lock); > > fdb = br_fdb_find(br, addr, vid); > - if (fdb && test_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->flags)) > + if (fdb && > + (test_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->flags) || > + test_bit(BR_FDB_OFFLOADED, &fdb->flags))) This also looks correct, but the function name is not really accurate anymore. I guess you can keep it as-is unless someone has a better name > fdb_delete(br, fdb, swdev_notify); > else > err = -ENOENT; > -- > 2.34.1 >
On 2023-02-01 19:24, Ido Schimmel wrote: > > This also looks correct, but the function name is not really accurate > anymore. I guess you can keep it as-is unless someone has a better name > >> fdb_delete(br, fdb, swdev_notify); >> else >> err = -ENOENT; >> -- >> 2.34.1 >> I have been wondering if it makes sense to have both external_learn and offloaded flags as they now work pretty much the same seen from the bridge. But as I don't know other switches, I guess there is some good reason to have the two?
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c index e69a872bfc1d..b0c23a72bc76 100644 --- a/net/bridge/br_fdb.c +++ b/net/bridge/br_fdb.c @@ -537,6 +537,7 @@ void br_fdb_cleanup(struct work_struct *work) unsigned long this_timer = f->updated + delay; if (test_bit(BR_FDB_STATIC, &f->flags) || + test_bit(BR_FDB_OFFLOADED, &f->flags) || test_bit(BR_FDB_ADDED_BY_EXT_LEARN, &f->flags)) { if (test_bit(BR_FDB_NOTIFY, &f->flags)) { if (time_after(this_timer, now)) @@ -1465,7 +1466,9 @@ int br_fdb_external_learn_del(struct net_bridge *br, struct net_bridge_port *p, spin_lock_bh(&br->hash_lock); fdb = br_fdb_find(br, addr, vid); - if (fdb && test_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->flags)) + if (fdb && + (test_bit(BR_FDB_ADDED_BY_EXT_LEARN, &fdb->flags) || + test_bit(BR_FDB_OFFLOADED, &fdb->flags))) fdb_delete(br, fdb, swdev_notify); else err = -ENOENT;