From patchwork Wed Jan 6 09:51:30 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12001227 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E39B9C433E0 for ; Wed, 6 Jan 2021 09:54:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9C63523104 for ; Wed, 6 Jan 2021 09:54:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726723AbhAFJww (ORCPT ); Wed, 6 Jan 2021 04:52:52 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42008 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726464AbhAFJwt (ORCPT ); Wed, 6 Jan 2021 04:52:49 -0500 Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DDA0AC061358; Wed, 6 Jan 2021 01:52:08 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id r5so3772610eda.12; Wed, 06 Jan 2021 01:52:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=16gvd7BfAcfkRnjtzWfjSCGdsSy14Us38+FznvZBJ7k=; b=PxNd/HwEcNRSVMr99MKoK3FzawQD6GjQmrNvZWYlyPKEozceeJEV7Feiql1pcoI7Rb wg9Zt1LmDZR/Etlg/TPais3DvwGsK0kA52gXrvdz3x5V7arW4lg0meHUobfoFNutshdR akA0NLol+kdv0LD0cnBx+X86WYao9mr97lZvRBN8UarkgQ6jGGLg41oqfkxAYRGlgq83 xjqgJv1WgXdxqNTWGb/Wtmt+UsDmvfAHhBBjbAdPm6MY9i+jwiHvcnvunQqgV0sxSyh0 EoghLxnZiY4BA9dIxr00RSdF0YWbcama5fTUCt6cnwd3n4r0u9PUIiq2H5TDULTe20Ck s88Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=16gvd7BfAcfkRnjtzWfjSCGdsSy14Us38+FznvZBJ7k=; b=OHckbzX7QDrtBpoM0j4en5N8o5339ads/CCHe54OKMLDQlmUFUvt2I0Xo0jvLgGe8U 7Vq0WlfCNHq2dTzeMkhZ6PKLvOunxw/fqWvK1jjXvTPnufB6NsiqV5u4FfR3jP32iAyq aZVwymiSSxorI0SJhXgHymF/d+asRDeA4OtFa8k71mx0VTSgRGRIh16+8EeVSI96PCQs RY6KKc7MsdfH9w92BIi2GWJUlcs9Xfbp6Zf7jbE7dW+zOiBtqQSWDck3LtUAGUPAwz9j gaN6rvxhx2h1tExW6eS56+jEvqMbHXHNAdZstLNJwVAaihtENhWc1xbIS0/3wDqgmQNd 5FFw== X-Gm-Message-State: AOAM532zgucgKUNW81NgmhOYlGxrH8YhuQD0IPmAqHhOvA0RYzEh3jtX 9RGFT6vjgFxCtDPojbcJh8U= X-Google-Smtp-Source: ABdhPJxktxJJg1wSJT44rdSR3ZWY7rdryDbFA1fGYDagD8Dp2gOqmN4tYEBT3tL4kBc/+HG/SGWznQ== X-Received: by 2002:aa7:c886:: with SMTP id p6mr3566884eds.352.1609926727634; Wed, 06 Jan 2021 01:52:07 -0800 (PST) Received: from localhost.localdomain (5-12-227-87.residential.rdsnet.ro. [5.12.227.87]) by smtp.gmail.com with ESMTPSA id n8sm1019587eju.33.2021.01.06.01.52.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jan 2021 01:52:07 -0800 (PST) From: Vladimir Oltean To: Andrew Lunn , Vivien Didelot , Florian Fainelli , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, Roopa Prabhu , Nikolay Aleksandrov , "David S. Miller" Cc: DENG Qingfang , Tobias Waldekranz , Marek Behun , Russell King - ARM Linux admin , Alexandra Winter , Jiri Pirko , Ido Schimmel , Claudiu Manoil , UNGLinuxDriver@microchip.com Subject: [PATCH v4 net-next 1/7] net: bridge: notify switchdev of disappearance of old FDB entry upon migration Date: Wed, 6 Jan 2021 11:51:30 +0200 Message-Id: <20210106095136.224739-2-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210106095136.224739-1-olteanv@gmail.com> References: <20210106095136.224739-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean Currently the bridge emits atomic switchdev notifications for dynamically learnt FDB entries. Monitoring these notifications works wonders for switchdev drivers that want to keep their hardware FDB in sync with the bridge's FDB. For example station A wants to talk to station B in the diagram below, and we are concerned with the behavior of the bridge on the DUT device: DUT +-------------------------------------+ | br0 | | +------+ +------+ +------+ +------+ | | | | | | | | | | | | | swp0 | | swp1 | | swp2 | | eth0 | | +-------------------------------------+ | | | Station A | | | | +--+------+--+ +--+------+--+ | | | | | | | | | | swp0 | | | | swp0 | | Another | +------+ | | +------+ | Another switch | br0 | | br0 | switch | +------+ | | +------+ | | | | | | | | | | | swp1 | | | | swp1 | | +--+------+--+ +--+------+--+ | Station B Interfaces swp0, swp1, swp2 are handled by a switchdev driver that has the following property: frames injected from its control interface bypass the internal address analyzer logic, and therefore, this hardware does not learn from the source address of packets transmitted by the network stack through it. So, since bridging between eth0 (where Station B is attached) and swp0 (where Station A is attached) is done in software, the switchdev hardware will never learn the source address of Station B. So the traffic towards that destination will be treated as unknown, i.e. flooded. This is where the bridge notifications come in handy. When br0 on the DUT sees frames with Station B's MAC address on eth0, the switchdev driver gets these notifications and can install a rule to send frames towards Station B's address that are incoming from swp0, swp1, swp2, only towards the control interface. This is all switchdev driver private business, which the notification makes possible. All is fine until someone unplugs Station B's cable and moves it to the other switch: DUT +-------------------------------------+ | br0 | | +------+ +------+ +------+ +------+ | | | | | | | | | | | | | swp0 | | swp1 | | swp2 | | eth0 | | +-------------------------------------+ | | | Station A | | | | +--+------+--+ +--+------+--+ | | | | | | | | | | swp0 | | | | swp0 | | Another | +------+ | | +------+ | Another switch | br0 | | br0 | switch | +------+ | | +------+ | | | | | | | | | | | swp1 | | | | swp1 | | +--+------+--+ +--+------+--+ | Station B Luckily for the use cases we care about, Station B is noisy enough that the DUT hears it (on swp1 this time). swp1 receives the frames and delivers them to the bridge, who enters the unlikely path in br_fdb_update of updating an existing entry. It moves the entry in the software bridge to swp1 and emits an addition notification towards that. As far as the switchdev driver is concerned, all that it needs to ensure is that traffic between Station A and Station B is not forever broken. If it does nothing, then the stale rule to send frames for Station B towards the control interface remains in place. But Station B is no longer reachable via the control interface, but via a port that can offload the bridge port learning attribute. It's just that the port is prevented from learning this address, since the rule overrides FDB updates. So the rule needs to go. The question is via what mechanism. It sure would be possible for this switchdev driver to keep track of all addresses which are sent to the control interface, and then also listen for bridge notifier events on its own ports, searching for the ones that have a MAC address which was previously sent to the control interface. But this is cumbersome and inefficient. Instead, with one small change, the bridge could notify of the address deletion from the old port, in a symmetrical manner with how it did for the insertion. Then the switchdev driver would not be required to monitor learn/forget events for its own ports. It could just delete the rule towards the control interface upon bridge entry migration. This would make hardware address learning be possible again. Then it would take a few more packets until the hardware and software FDB would be in sync again. Signed-off-by: Vladimir Oltean Acked-by: Nikolay Aleksandrov Reviewed-by: Ido Schimmel Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli --- Changes in v4: None. Changes in v3: None. Changes in v2: Patch is new. net/bridge/br_fdb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c index 32ac8343b0ba..b7490237f3fc 100644 --- a/net/bridge/br_fdb.c +++ b/net/bridge/br_fdb.c @@ -602,6 +602,7 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source, /* fastpath: update of existing entry */ if (unlikely(source != fdb->dst && !test_bit(BR_FDB_STICKY, &fdb->flags))) { + br_switchdev_fdb_notify(fdb, RTM_DELNEIGH); fdb->dst = source; fdb_modified = true; /* Take over HW learned entry */ From patchwork Wed Jan 6 09:51:31 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12001217 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 51041C433E0 for ; Wed, 6 Jan 2021 09:53:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 051B323117 for ; Wed, 6 Jan 2021 09:53:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726464AbhAFJwx (ORCPT ); Wed, 6 Jan 2021 04:52:53 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42014 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726624AbhAFJwu (ORCPT ); Wed, 6 Jan 2021 04:52:50 -0500 Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 51B66C061359; Wed, 6 Jan 2021 01:52:10 -0800 (PST) Received: by mail-ej1-x632.google.com with SMTP id lt17so4279998ejb.3; Wed, 06 Jan 2021 01:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Oyqqq/X9qdu3xx65zVGG4PWH/PNLT4F1km7kqg9CwhU=; b=gzddoHJOCVay1ZtwAg6gpZYehIhSRqUIQSdK4JUH+wPjfbt4c780257hgbJRUZZ0ZC i9KHrBmIsFtgQvFjDsTf2XoSa4rJGVoyx/WKywr3FvG1ot0/gXU9nB+lWK6l+aFqxR0R LvcGmC+ZWUIbjKMYyuMmV6a7Ur40nOQSw/CVGIrtgjg778xGuFveUJfmadVczelFyf0W M/0XtJ4D4x2wgj7yI+dTV5HRtqEtO410+bkvou21VP4UP767x4tRzG2mSrouCS+UN7Ic 7yhz8MtN27k2KQwgU83zQiyXSq13jEdR2prrmCrKgp+BkOJML+CaYOOFNa/sWxQJ5igr 0HvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Oyqqq/X9qdu3xx65zVGG4PWH/PNLT4F1km7kqg9CwhU=; b=K/s8h7TXHjbnBNbOzkq24YfU2iunsLSRrB6KOXlz7hy5rYSQ6c3PTu4Ix4OwXUGTxw eTcWK7bYOW3/ScGhPSGp/nV3RgyycyYqMtaxip7Uuw9uaeHV/ON+zEstsi816ZnQsd5+ oBnsIjsDEmhcq53jZIJ4YIET0tO+jXbO+J8U4HyAJ4CNzHpm6MKm38giySURFwlkURtc R7l3pN2jscphi2xfzNYXtGmjsM4pWb2a4oNbJGI9Vtm7wGD8Ff4fopNwoDd3svMPPFRI E+ESb7T7dI0TqWSTN8k3NC7T3acMWe0PAz86FGhvqwibo/8ynTWitJoVcnAhEd5OV4vE 3OUQ== X-Gm-Message-State: AOAM5326clLf2/cumM3lROizvqkdf4cGtTjwQ8x5+JMGSQmg+SpGTgyd h/v93sUaRSelgBvlcQryf7k= X-Google-Smtp-Source: ABdhPJzq0FCe5EV/63tubiMzkQ44Wkkk+QVgy3AIICkXzaUOGz8TCuIvKt45D+hHVgZ5EO/NiUKvjg== X-Received: by 2002:a17:906:118c:: with SMTP id n12mr2377284eja.167.1609926729109; Wed, 06 Jan 2021 01:52:09 -0800 (PST) Received: from localhost.localdomain (5-12-227-87.residential.rdsnet.ro. [5.12.227.87]) by smtp.gmail.com with ESMTPSA id n8sm1019587eju.33.2021.01.06.01.52.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jan 2021 01:52:08 -0800 (PST) From: Vladimir Oltean To: Andrew Lunn , Vivien Didelot , Florian Fainelli , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, Roopa Prabhu , Nikolay Aleksandrov , "David S. Miller" Cc: DENG Qingfang , Tobias Waldekranz , Marek Behun , Russell King - ARM Linux admin , Alexandra Winter , Jiri Pirko , Ido Schimmel , Claudiu Manoil , UNGLinuxDriver@microchip.com Subject: [PATCH v4 net-next 2/7] net: dsa: be louder when a non-legacy FDB operation fails Date: Wed, 6 Jan 2021 11:51:31 +0200 Message-Id: <20210106095136.224739-3-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210106095136.224739-1-olteanv@gmail.com> References: <20210106095136.224739-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean The dev_close() call was added in commit c9eb3e0f8701 ("net: dsa: Add support for learning FDB through notification") "to indicate inconsistent situation" when we could not delete an FDB entry from the port. bridge fdb del d8:58:d7:00:ca:6d dev swp0 self master It is a bit drastic and at the same time not helpful if the above fails to only print with netdev_dbg log level, but on the other hand to bring the interface down. So increase the verbosity of the error message, and drop dev_close(). Signed-off-by: Vladimir Oltean Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli --- Changes in v4: None. Changes in v3: Patch is new. net/dsa/slave.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/net/dsa/slave.c b/net/dsa/slave.c index 4a0498bf6c65..d5d389300124 100644 --- a/net/dsa/slave.c +++ b/net/dsa/slave.c @@ -2072,7 +2072,9 @@ static void dsa_slave_switchdev_event_work(struct work_struct *work) err = dsa_port_fdb_add(dp, fdb_info->addr, fdb_info->vid); if (err) { - netdev_dbg(dev, "fdb add failed err=%d\n", err); + netdev_err(dev, + "failed to add %pM vid %d to fdb: %d\n", + fdb_info->addr, fdb_info->vid, err); break; } fdb_info->offloaded = true; @@ -2087,9 +2089,11 @@ static void dsa_slave_switchdev_event_work(struct work_struct *work) err = dsa_port_fdb_del(dp, fdb_info->addr, fdb_info->vid); if (err) { - netdev_dbg(dev, "fdb del failed err=%d\n", err); - dev_close(dev); + netdev_err(dev, + "failed to delete %pM vid %d from fdb: %d\n", + fdb_info->addr, fdb_info->vid, err); } + break; } rtnl_unlock(); From patchwork Wed Jan 6 09:51:32 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12001223 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7215EC43331 for ; Wed, 6 Jan 2021 09:53:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 515A323120 for ; Wed, 6 Jan 2021 09:53:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726915AbhAFJxE (ORCPT ); Wed, 6 Jan 2021 04:53:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42022 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726700AbhAFJww (ORCPT ); Wed, 6 Jan 2021 04:52:52 -0500 Received: from mail-ej1-x62d.google.com (mail-ej1-x62d.google.com [IPv6:2a00:1450:4864:20::62d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D073DC06135A; Wed, 6 Jan 2021 01:52:11 -0800 (PST) Received: by mail-ej1-x62d.google.com with SMTP id jx16so4167629ejb.10; Wed, 06 Jan 2021 01:52:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=sCI60LCZ1+oOYN2OaqOsvPgH+ncwP3mrKDvgQ0kdXH8=; b=o5qPM/NIfrqc2/DSnZtP9ZM8V+da04ThaFNS4dwFAQrzpZi7aZusnLa0zKHyLibWBf SZF7zvnJ4dpnL4rh9KkTp2jYtJ2N0fButXLmP2y6+aGDLk3dfBBrQv+LYQadn+k4DqX5 9+RoPy+NWQLym1TjGykaKUcK2PHHWYFPd3MvN03hHhTKh305P5g8mfXQmAEKLAD6CMcc qurUdbSJQykDn3XaoI6SdgN2W2xzc9kklwE0C9NO93TfQ30vIM9f+KAr0sRyWV14SuzO eV5xzbnyZ99VvAOVMQAwLCLwylflabCggWwIpmU/t+4Q5NjdGc6siKt9iW/QDjzRK9M7 /Abg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=sCI60LCZ1+oOYN2OaqOsvPgH+ncwP3mrKDvgQ0kdXH8=; b=klvtLHE0W9JvvIxeTQzcHug3hA8P8wTOwyRvrRb14MiBz8RzH09oarya86tsy1qpGk Eg4OXcINMD1CnVkFW5Km/awXzpB/RkD18Jxnek0sx+Y2dkeCY/BNktArx5sCn0Uf6a3r vT9AM/WSclQ0hiwW3YUFidEjARMOX9+Uqf7Tt0kGwVYcKGoEpyEpp0IXmkIiKCDg8ePe RsMb3GHTMvmZ5bdeOQ0AxmUfCZ6FKpSdq2iAQQZC3Nx4wJq5u3gyvae6Iom+g9zMkJUw dMi1cxQFpxxrg2JEEUUHrknIl+meUewtlo+2EDC0i5cLE0keKATK1ijsLhHg9Diqwy1W KE5Q== X-Gm-Message-State: AOAM5318Q4SIR0bJDFr6TMAJ//Fqc6PnxT2H934hCXAXzXnaAR0SMsxW ZsFc0EqPud4ACBIUtNHTiB73O2Ud51g= X-Google-Smtp-Source: ABdhPJxn/hzsGCwb3PJ4c9drXUo5v8eBQ1PSMv3cGz1gk4Nx6CO9U3EtS2oxpXcZJLzaavYPYSvAMA== X-Received: by 2002:a17:906:3513:: with SMTP id r19mr2230236eja.445.1609926730585; Wed, 06 Jan 2021 01:52:10 -0800 (PST) Received: from localhost.localdomain (5-12-227-87.residential.rdsnet.ro. [5.12.227.87]) by smtp.gmail.com with ESMTPSA id n8sm1019587eju.33.2021.01.06.01.52.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jan 2021 01:52:10 -0800 (PST) From: Vladimir Oltean To: Andrew Lunn , Vivien Didelot , Florian Fainelli , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, Roopa Prabhu , Nikolay Aleksandrov , "David S. Miller" Cc: DENG Qingfang , Tobias Waldekranz , Marek Behun , Russell King - ARM Linux admin , Alexandra Winter , Jiri Pirko , Ido Schimmel , Claudiu Manoil , UNGLinuxDriver@microchip.com Subject: [PATCH v4 net-next 3/7] net: dsa: don't use switchdev_notifier_fdb_info in dsa_switchdev_event_work Date: Wed, 6 Jan 2021 11:51:32 +0200 Message-Id: <20210106095136.224739-4-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210106095136.224739-1-olteanv@gmail.com> References: <20210106095136.224739-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean Currently DSA doesn't add FDB entries on the CPU port, because it only does so through switchdev, which is associated with a net_device, and there are none of those for the CPU port. But actually FDB addresses on the CPU port have some use cases of their own, if the switchdev operations are initiated from within the DSA layer. There is just one problem with the existing code: it passes a structure in dsa_switchdev_event_work which was retrieved directly from switchdev, so it contains a net_device. We need to generalize the contents to something that covers the CPU port as well: the "ds, port" tuple is fine for that. Note that the new procedure for notifying the successful FDB offload is inspired from the rocker model. Also, nothing was being done if added_by_user was false. Let's check for that a lot earlier, and don't actually bother to schedule the worker for nothing. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli --- Changes in v4: None. Changes in v3: None. Changes in v2: Small cosmetic changes (reverse Christmas notation) net/dsa/dsa_priv.h | 12 +++++ net/dsa/slave.c | 106 ++++++++++++++++++++++----------------------- 2 files changed, 65 insertions(+), 53 deletions(-) diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h index 7c96aae9062c..c04225f74929 100644 --- a/net/dsa/dsa_priv.h +++ b/net/dsa/dsa_priv.h @@ -73,6 +73,18 @@ struct dsa_notifier_mtu_info { int mtu; }; +struct dsa_switchdev_event_work { + struct dsa_switch *ds; + int port; + struct work_struct work; + unsigned long event; + /* Specific for SWITCHDEV_FDB_ADD_TO_DEVICE and + * SWITCHDEV_FDB_DEL_TO_DEVICE + */ + unsigned char addr[ETH_ALEN]; + u16 vid; +}; + struct dsa_slave_priv { /* Copy of CPU port xmit for faster access in slave transmit hot path */ struct sk_buff * (*xmit)(struct sk_buff *skb, diff --git a/net/dsa/slave.c b/net/dsa/slave.c index d5d389300124..5e4fb44c2820 100644 --- a/net/dsa/slave.c +++ b/net/dsa/slave.c @@ -2047,76 +2047,66 @@ static int dsa_slave_netdevice_event(struct notifier_block *nb, return NOTIFY_DONE; } -struct dsa_switchdev_event_work { - struct work_struct work; - struct switchdev_notifier_fdb_info fdb_info; - struct net_device *dev; - unsigned long event; -}; +static void +dsa_fdb_offload_notify(struct dsa_switchdev_event_work *switchdev_work) +{ + struct dsa_switch *ds = switchdev_work->ds; + struct switchdev_notifier_fdb_info info; + struct dsa_port *dp; + + if (!dsa_is_user_port(ds, switchdev_work->port)) + return; + + info.addr = switchdev_work->addr; + info.vid = switchdev_work->vid; + info.offloaded = true; + dp = dsa_to_port(ds, switchdev_work->port); + call_switchdev_notifiers(SWITCHDEV_FDB_OFFLOADED, + dp->slave, &info.info, NULL); +} static void dsa_slave_switchdev_event_work(struct work_struct *work) { struct dsa_switchdev_event_work *switchdev_work = container_of(work, struct dsa_switchdev_event_work, work); - struct net_device *dev = switchdev_work->dev; - struct switchdev_notifier_fdb_info *fdb_info; - struct dsa_port *dp = dsa_slave_to_port(dev); + struct dsa_switch *ds = switchdev_work->ds; + struct dsa_port *dp; int err; + dp = dsa_to_port(ds, switchdev_work->port); + rtnl_lock(); switch (switchdev_work->event) { case SWITCHDEV_FDB_ADD_TO_DEVICE: - fdb_info = &switchdev_work->fdb_info; - if (!fdb_info->added_by_user) - break; - - err = dsa_port_fdb_add(dp, fdb_info->addr, fdb_info->vid); + err = dsa_port_fdb_add(dp, switchdev_work->addr, + switchdev_work->vid); if (err) { - netdev_err(dev, - "failed to add %pM vid %d to fdb: %d\n", - fdb_info->addr, fdb_info->vid, err); + dev_err(ds->dev, + "port %d failed to add %pM vid %d to fdb: %d\n", + dp->index, switchdev_work->addr, + switchdev_work->vid, err); break; } - fdb_info->offloaded = true; - call_switchdev_notifiers(SWITCHDEV_FDB_OFFLOADED, dev, - &fdb_info->info, NULL); + dsa_fdb_offload_notify(switchdev_work); break; case SWITCHDEV_FDB_DEL_TO_DEVICE: - fdb_info = &switchdev_work->fdb_info; - if (!fdb_info->added_by_user) - break; - - err = dsa_port_fdb_del(dp, fdb_info->addr, fdb_info->vid); + err = dsa_port_fdb_del(dp, switchdev_work->addr, + switchdev_work->vid); if (err) { - netdev_err(dev, - "failed to delete %pM vid %d from fdb: %d\n", - fdb_info->addr, fdb_info->vid, err); + dev_err(ds->dev, + "port %d failed to delete %pM vid %d from fdb: %d\n", + dp->index, switchdev_work->addr, + switchdev_work->vid, err); } break; } rtnl_unlock(); - kfree(switchdev_work->fdb_info.addr); kfree(switchdev_work); - dev_put(dev); -} - -static int -dsa_slave_switchdev_fdb_work_init(struct dsa_switchdev_event_work * - switchdev_work, - const struct switchdev_notifier_fdb_info * - fdb_info) -{ - memcpy(&switchdev_work->fdb_info, fdb_info, - sizeof(switchdev_work->fdb_info)); - switchdev_work->fdb_info.addr = kzalloc(ETH_ALEN, GFP_ATOMIC); - if (!switchdev_work->fdb_info.addr) - return -ENOMEM; - ether_addr_copy((u8 *)switchdev_work->fdb_info.addr, - fdb_info->addr); - return 0; + if (dsa_is_user_port(ds, dp->index)) + dev_put(dp->slave); } /* Called under rcu_read_lock() */ @@ -2124,7 +2114,9 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused, unsigned long event, void *ptr) { struct net_device *dev = switchdev_notifier_info_to_dev(ptr); + const struct switchdev_notifier_fdb_info *fdb_info; struct dsa_switchdev_event_work *switchdev_work; + struct dsa_port *dp; int err; if (event == SWITCHDEV_PORT_ATTR_SET) { @@ -2137,20 +2129,32 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused, if (!dsa_slave_dev_check(dev)) return NOTIFY_DONE; + dp = dsa_slave_to_port(dev); + switchdev_work = kzalloc(sizeof(*switchdev_work), GFP_ATOMIC); if (!switchdev_work) return NOTIFY_BAD; INIT_WORK(&switchdev_work->work, dsa_slave_switchdev_event_work); - switchdev_work->dev = dev; + switchdev_work->ds = dp->ds; + switchdev_work->port = dp->index; switchdev_work->event = event; switch (event) { case SWITCHDEV_FDB_ADD_TO_DEVICE: case SWITCHDEV_FDB_DEL_TO_DEVICE: - if (dsa_slave_switchdev_fdb_work_init(switchdev_work, ptr)) - goto err_fdb_work_init; + fdb_info = ptr; + + if (!fdb_info->added_by_user) { + kfree(switchdev_work); + return NOTIFY_OK; + } + + ether_addr_copy(switchdev_work->addr, + fdb_info->addr); + switchdev_work->vid = fdb_info->vid; + dev_hold(dev); break; default: @@ -2160,10 +2164,6 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused, dsa_schedule_work(&switchdev_work->work); return NOTIFY_OK; - -err_fdb_work_init: - kfree(switchdev_work); - return NOTIFY_BAD; } static int dsa_slave_switchdev_blocking_event(struct notifier_block *unused, From patchwork Wed Jan 6 09:51:33 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12001221 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6B7C4C4332B for ; Wed, 6 Jan 2021 09:53:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 293882312E for ; Wed, 6 Jan 2021 09:53:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726957AbhAFJxE (ORCPT ); Wed, 6 Jan 2021 04:53:04 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42044 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726828AbhAFJxC (ORCPT ); Wed, 6 Jan 2021 04:53:02 -0500 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 570A7C06135B; Wed, 6 Jan 2021 01:52:13 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id q22so4300311eja.2; Wed, 06 Jan 2021 01:52:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=lC1LFiqDpicLin+YkECJxc7NkcTGlHpSR10OKpi+kks=; b=MMn0MBO1IZucAJil43VtDtQ9f/QhqzBoa/oWw9wIy2YCE59+Sjl2dDA9MMf0xia1H2 eUh4zmvJqx2rP/Qv/ouqkMTvJXy8Yr+MrrOG+MndqjCTDdELMMS4PPSliKugftc7ZroU iFr1cfBkJDRuQQtas2XnCz52k8RQhJV6QO2Q1SNEM8mSSiyQmhIbnHINPhMfRAC2Qbnk HtqEpxtKGKfq1hO87BLdqKn2jXFW5EHdcccTUAyKT/FGDGl36rMc6m/ebNqE4sO+qR+Y hCOnFo6hSoNE9R3e9cKnBXuKq6YCAqkCnDaIFtwWEF8hxlet1OBxoCNs6zYtLu85UhRH U9wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=lC1LFiqDpicLin+YkECJxc7NkcTGlHpSR10OKpi+kks=; b=SJZaJMQm6g94d/agSyZn+htjdqRgpAF3dd/ExyMFpWpPD/IzqzipKfiW3F2ZX7TBkl xYfVdZx9suRoG2OupvLtPnbdQ3hB1LxIGIadNYTepYSc9bdyVH7CYLT5zIeDDL5Vc2vy ENkEFWgeARZjQHc3sYePMEx1XRuVJK3MKzYChXoCEe6Cll2n3/r+6zOfnR8/FRxM1cKb oLAkrc5bMEZBWufFG/ICL+wSJsoRV2kAlrWya17rZxkozMqfd6adJ45TwCCwJHJ0er+B cvOI1Z2/TlfR2X4yUwQ6tbqlXpiBYqaqGQDLPChw9A7ScQPeyHSKiSlYqSpPIYOX+tvs fnAw== X-Gm-Message-State: AOAM530w4i9lbAD16/zS8pGqMGys/mR2KBB3wMWRYslTU5dX+QyNn6IX hSjK8XcJBWyccaP+EzWRYnM= X-Google-Smtp-Source: ABdhPJwT0MuQxw54+W0T9eTfecMbPn2xm8U8M6W+sooSKxUngin825dSUjpqb2DvXgnlx63HNc3sGQ== X-Received: by 2002:a17:906:578e:: with SMTP id k14mr2360423ejq.90.1609926732066; Wed, 06 Jan 2021 01:52:12 -0800 (PST) Received: from localhost.localdomain (5-12-227-87.residential.rdsnet.ro. [5.12.227.87]) by smtp.gmail.com with ESMTPSA id n8sm1019587eju.33.2021.01.06.01.52.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jan 2021 01:52:11 -0800 (PST) From: Vladimir Oltean To: Andrew Lunn , Vivien Didelot , Florian Fainelli , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, Roopa Prabhu , Nikolay Aleksandrov , "David S. Miller" Cc: DENG Qingfang , Tobias Waldekranz , Marek Behun , Russell King - ARM Linux admin , Alexandra Winter , Jiri Pirko , Ido Schimmel , Claudiu Manoil , UNGLinuxDriver@microchip.com Subject: [PATCH v4 net-next 4/7] net: dsa: move switchdev event implementation under the same switch/case statement Date: Wed, 6 Jan 2021 11:51:33 +0200 Message-Id: <20210106095136.224739-5-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210106095136.224739-1-olteanv@gmail.com> References: <20210106095136.224739-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean We'll need to start listening to SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE events even for interfaces where dsa_slave_dev_check returns false, so we need that check inside the switch-case statement for SWITCHDEV_FDB_*. This movement also avoids a useless allocation / free of switchdev_work on the untreated "default event" case. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli --- Changes in v4: None. Changes in v3: None. Changes in v2: None. net/dsa/slave.c | 35 ++++++++++++++++------------------- 1 file changed, 16 insertions(+), 19 deletions(-) diff --git a/net/dsa/slave.c b/net/dsa/slave.c index 5e4fb44c2820..42ec18a4c7ba 100644 --- a/net/dsa/slave.c +++ b/net/dsa/slave.c @@ -2119,31 +2119,29 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused, struct dsa_port *dp; int err; - if (event == SWITCHDEV_PORT_ATTR_SET) { + switch (event) { + case SWITCHDEV_PORT_ATTR_SET: err = switchdev_handle_port_attr_set(dev, ptr, dsa_slave_dev_check, dsa_slave_port_attr_set); return notifier_from_errno(err); - } - - if (!dsa_slave_dev_check(dev)) - return NOTIFY_DONE; + case SWITCHDEV_FDB_ADD_TO_DEVICE: + case SWITCHDEV_FDB_DEL_TO_DEVICE: + if (!dsa_slave_dev_check(dev)) + return NOTIFY_DONE; - dp = dsa_slave_to_port(dev); + dp = dsa_slave_to_port(dev); - switchdev_work = kzalloc(sizeof(*switchdev_work), GFP_ATOMIC); - if (!switchdev_work) - return NOTIFY_BAD; + switchdev_work = kzalloc(sizeof(*switchdev_work), GFP_ATOMIC); + if (!switchdev_work) + return NOTIFY_BAD; - INIT_WORK(&switchdev_work->work, - dsa_slave_switchdev_event_work); - switchdev_work->ds = dp->ds; - switchdev_work->port = dp->index; - switchdev_work->event = event; + INIT_WORK(&switchdev_work->work, + dsa_slave_switchdev_event_work); + switchdev_work->ds = dp->ds; + switchdev_work->port = dp->index; + switchdev_work->event = event; - switch (event) { - case SWITCHDEV_FDB_ADD_TO_DEVICE: - case SWITCHDEV_FDB_DEL_TO_DEVICE: fdb_info = ptr; if (!fdb_info->added_by_user) { @@ -2156,13 +2154,12 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused, switchdev_work->vid = fdb_info->vid; dev_hold(dev); + dsa_schedule_work(&switchdev_work->work); break; default: - kfree(switchdev_work); return NOTIFY_DONE; } - dsa_schedule_work(&switchdev_work->work); return NOTIFY_OK; } From patchwork Wed Jan 6 09:51:34 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12001219 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4861C433E6 for ; Wed, 6 Jan 2021 09:53:24 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8023423104 for ; Wed, 6 Jan 2021 09:53:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726874AbhAFJxD (ORCPT ); Wed, 6 Jan 2021 04:53:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726830AbhAFJxC (ORCPT ); Wed, 6 Jan 2021 04:53:02 -0500 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E1654C06135C; Wed, 6 Jan 2021 01:52:14 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id i24so3828390edj.8; Wed, 06 Jan 2021 01:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=yF3rnLTyQNwA21TyP52ciWlNhWGg2itKNaVkTO2/cDA=; b=V6RtY4DS+UNCW6fua0p/m79afdROsP11C0PquKtYRn2kbdiNrCrgy7y6M/h+MXGVQP q4Dx+GPHMSamQ4qCkjtNGolJEYlY0fDQCEF36qoySnoe2UrtWpBQ5QdSydtSI68Clx5b hMaGW05NJvB+f6iNIPZHZensNo0ntRUM4JNk9DZ9tz19cbBEQnvu0LMdFh4ehjOQ/k41 hMmY4DRE8QMJDh4eErCfywL82gw7kC31uiT/Px/XwK2JW6QK9oHLrwS+UcnrCUmdNSSL A4oCXrvEQ4Rukl7UDY3nSBiHsmUGqghaca8EQuWNG08bIwGktNOLZ4kllyQfgJjPQDOT L9oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=yF3rnLTyQNwA21TyP52ciWlNhWGg2itKNaVkTO2/cDA=; b=fWpsPj1stTxhqJVxsufNqv3fc1Ao6ZTFzDhBeaLRk1mJV4rh988TYoMBTKJSUqqkFF kzYntQU/Srv/M+OIm+KPDRPxGHCSlHH1O9moEpE415YXfN+Eb6VdXcHxf1AaTBSYGDAX Zyl+Wby9XTdkLUjwQkgsnP2jGHK791xXp/AmrBwTmjfIqoEg8J/Tobz6eVr44tJeKXzQ 2l7reWH/enev2b/9DO+xqq1BvsdoUMpmKCFuZgwKSv8XxZW2AOjJxxJopj1/p0vNfwA1 NWeAQ+Oz7O3W7/aHRoOcOtezmiShlkOI4dgq4lkVjFr9WJJ7y3k21h2pe6O4Ke6rovNz U2ig== X-Gm-Message-State: AOAM530J4izFZ++J20e8B6ad01qOa+3lNwg/iY1ecosE0LIcVDVNnA61 yl1fQYBf0kH2Zd5jGs4yd2kDJ1N0GjU= X-Google-Smtp-Source: ABdhPJzTQaqy8VXeMTSaAYqUwxQFJr8Tf4SYo0dqaCd3QeTpmzC07iD46TQwKp0I0Q6h+rvjDTaAcA== X-Received: by 2002:a50:f1c7:: with SMTP id y7mr3495727edl.184.1609926733626; Wed, 06 Jan 2021 01:52:13 -0800 (PST) Received: from localhost.localdomain (5-12-227-87.residential.rdsnet.ro. [5.12.227.87]) by smtp.gmail.com with ESMTPSA id n8sm1019587eju.33.2021.01.06.01.52.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jan 2021 01:52:13 -0800 (PST) From: Vladimir Oltean To: Andrew Lunn , Vivien Didelot , Florian Fainelli , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, Roopa Prabhu , Nikolay Aleksandrov , "David S. Miller" Cc: DENG Qingfang , Tobias Waldekranz , Marek Behun , Russell King - ARM Linux admin , Alexandra Winter , Jiri Pirko , Ido Schimmel , Claudiu Manoil , UNGLinuxDriver@microchip.com Subject: [PATCH v4 net-next 5/7] net: dsa: exit early in dsa_slave_switchdev_event if we can't program the FDB Date: Wed, 6 Jan 2021 11:51:34 +0200 Message-Id: <20210106095136.224739-6-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210106095136.224739-1-olteanv@gmail.com> References: <20210106095136.224739-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean Right now, the following would happen for a switch driver that does not implement .port_fdb_add or .port_fdb_del. dsa_slave_switchdev_event returns NOTIFY_OK and schedules: -> dsa_slave_switchdev_event_work -> dsa_port_fdb_add -> dsa_port_notify(DSA_NOTIFIER_FDB_ADD) -> dsa_switch_fdb_add -> if (!ds->ops->port_fdb_add) return -EOPNOTSUPP; -> an error is printed with dev_dbg, and dsa_fdb_offload_notify(switchdev_work) is not called. We can avoid scheduling the worker for nothing and say NOTIFY_DONE. Because we don't call dsa_fdb_offload_notify, the static FDB entry will remain just in the software bridge. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn --- Changes in v4: None. Changes in v3: s/NOTIFY_OK/NOTIFY_DONE/ in commit description. Changes in v2: Patch is new. net/dsa/slave.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/dsa/slave.c b/net/dsa/slave.c index 42ec18a4c7ba..37dffe5bc46f 100644 --- a/net/dsa/slave.c +++ b/net/dsa/slave.c @@ -2132,6 +2132,9 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused, dp = dsa_slave_to_port(dev); + if (!dp->ds->ops->port_fdb_add || !dp->ds->ops->port_fdb_del) + return NOTIFY_DONE; + switchdev_work = kzalloc(sizeof(*switchdev_work), GFP_ATOMIC); if (!switchdev_work) return NOTIFY_BAD; From patchwork Wed Jan 6 09:51:35 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12001225 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DB5E5C43333 for ; Wed, 6 Jan 2021 09:53:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B27902310D for ; Wed, 6 Jan 2021 09:53:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727089AbhAFJxR (ORCPT ); Wed, 6 Jan 2021 04:53:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726828AbhAFJxP (ORCPT ); Wed, 6 Jan 2021 04:53:15 -0500 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7B778C06135D; Wed, 6 Jan 2021 01:52:16 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id g20so4315882ejb.1; Wed, 06 Jan 2021 01:52:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=phqppXF2ASkYJBnKfnD9JVsXRh5ajmKCs6dbXHVV5JE=; b=Y4SSa0hUBT6no6paikQ0JSBPvJcjLtwDagAfFikxLVGhTC9zZyKOjWpa9hlANtXRxl bBT7xckv+zZKIKNrUM9udLN0vglT5eLuBCTiwqHLvb2ZYSAeA7h4tn/TX+gIMTmUg2jE QR1iMj5LTLTlv+VU4+we9jdRLI7YsYtFRUgCRCcLdkoTJhJvqhlYXJtHb6k/4M+ttjmL 6LmQi4lcwX6cdU5od3eA+VPY9YqcRu9r6NMg8ePgnaJWFiG889qfW6gkOLPTkno1iduS vCKN/xXt4Zz/iryOmx0wBR2eiEwqLc+YFMLkO6JEerIsWNVNkgSyDkAysp6N9IvfDfqr 4Azg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=phqppXF2ASkYJBnKfnD9JVsXRh5ajmKCs6dbXHVV5JE=; b=mjOA+sXoCRGSKfwCztTLdZILOUFUC/1JSZo6EzrFOCrQiINro6qH4RdXzk4HTAEWWs igzb0Q2aa8N+lcs3Fyok1l939Dzx+36YvtcjfOGqjMRMHHvpUrxTjj6k2JpgTr9/cLGn qLOadR4zWtoxkyu7jniv+pGVPmjmR2fFJQPEVZ/h9hjqQzc7Rxd2NReIDYRxCPniPupw ZGucCki0pvSRQGXxueZaiWjClX2Skxy1J8GrkxsCx6V9VUWitcXl1+EzCNHZGupyLVeN bOImvH0hJPGOotvrCqy51K0BSDh2jQdei+6eLfE7V+/oTh/9890Caq+PSWxXrEtR0NJo VdFg== X-Gm-Message-State: AOAM533ZAb7H+lhXb2dNQrxDol5YsESfV5VCVnp7ElV6rb48Ma3HVRH/ En1ipYpklT0dsTD09rAG+18= X-Google-Smtp-Source: ABdhPJwa8CzgsDoN3xPz+815tW3AUxEZrUGidPakUNPV6dLZgvGDREjX1BhC4+2hzNKmIs7lcUTQpA== X-Received: by 2002:a17:906:52da:: with SMTP id w26mr2331397ejn.347.1609926735172; Wed, 06 Jan 2021 01:52:15 -0800 (PST) Received: from localhost.localdomain (5-12-227-87.residential.rdsnet.ro. [5.12.227.87]) by smtp.gmail.com with ESMTPSA id n8sm1019587eju.33.2021.01.06.01.52.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jan 2021 01:52:14 -0800 (PST) From: Vladimir Oltean To: Andrew Lunn , Vivien Didelot , Florian Fainelli , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, Roopa Prabhu , Nikolay Aleksandrov , "David S. Miller" Cc: DENG Qingfang , Tobias Waldekranz , Marek Behun , Russell King - ARM Linux admin , Alexandra Winter , Jiri Pirko , Ido Schimmel , Claudiu Manoil , UNGLinuxDriver@microchip.com Subject: [PATCH v4 net-next 6/7] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors Date: Wed, 6 Jan 2021 11:51:35 +0200 Message-Id: <20210106095136.224739-7-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210106095136.224739-1-olteanv@gmail.com> References: <20210106095136.224739-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean Some DSA switches (and not only) cannot learn source MAC addresses from packets injected from the CPU. They only perform hardware address learning from inbound traffic. This can be problematic when we have a bridge spanning some DSA switch ports and some non-DSA ports (which we'll call "foreign interfaces" from DSA's perspective). There are 2 classes of problems created by the lack of learning on CPU-injected traffic: - excessive flooding, due to the fact that DSA treats those addresses as unknown - the risk of stale routes, which can lead to temporary packet loss To illustrate the second class, consider the following situation, which is common in production equipment (wireless access points, where there is a WLAN interface and an Ethernet switch, and these form a single bridging domain). AP 1: +------------------------------------------------------------------------+ | br0 | +------------------------------------------------------------------------+ +------------+ +------------+ +------------+ +------------+ +------------+ | swp0 | | swp1 | | swp2 | | swp3 | | wlan0 | +------------+ +------------+ +------------+ +------------+ +------------+ | ^ ^ | | | | | | | Client A Client B | | | +------------+ +------------+ +------------+ +------------+ +------------+ | swp0 | | swp1 | | swp2 | | swp3 | | wlan0 | +------------+ +------------+ +------------+ +------------+ +------------+ +------------------------------------------------------------------------+ | br0 | +------------------------------------------------------------------------+ AP 2 - br0 of AP 1 will know that Clients A and B are reachable via wlan0 - the hardware fdb of a DSA switch driver today is not kept in sync with the software entries on other bridge ports, so it will not know that clients A and B are reachable via the CPU port UNLESS the hardware switch itself performs SA learning from traffic injected from the CPU. Nonetheless, a substantial number of switches don't. - the hardware fdb of the DSA switch on AP 2 may autonomously learn that Client A and B are reachable through swp0. Therefore, the software br0 of AP 2 also may or may not learn this. In the example we're illustrating, some Ethernet traffic has been going on, and br0 from AP 2 has indeed learnt that it can reach Client B through swp0. One of the wireless clients, say Client B, disconnects from AP 1 and roams to AP 2. The topology now looks like this: AP 1: +------------------------------------------------------------------------+ | br0 | +------------------------------------------------------------------------+ +------------+ +------------+ +------------+ +------------+ +------------+ | swp0 | | swp1 | | swp2 | | swp3 | | wlan0 | +------------+ +------------+ +------------+ +------------+ +------------+ | ^ | | | Client A | | | Client B | | | v +------------+ +------------+ +------------+ +------------+ +------------+ | swp0 | | swp1 | | swp2 | | swp3 | | wlan0 | +------------+ +------------+ +------------+ +------------+ +------------+ +------------------------------------------------------------------------+ | br0 | +------------------------------------------------------------------------+ AP 2 - br0 of AP 1 still knows that Client A is reachable via wlan0 (no change) - br0 of AP 1 will (possibly) know that Client B has left wlan0. There are cases where it might never find out though. Either way, DSA today does not process that notification in any way. - the hardware FDB of the DSA switch on AP 1 may learn autonomously that Client B can be reached via swp0, if it receives any packet with Client 1's source MAC address over Ethernet. - the hardware FDB of the DSA switch on AP 2 still thinks that Client B can be reached via swp0. It does not know that it has roamed to wlan0, because it doesn't perform SA learning from the CPU port. Now Client A contacts Client B. AP 1 routes the packet fine towards swp0 and delivers it on the Ethernet segment. AP 2 sees a frame on swp0 and its fdb says that the destination is swp0. Hairpinning is disabled => drop. This problem comes from the fact that these switches have a 'blind spot' for addresses coming from software bridging. The generic solution is not to assume that hardware learning can be enabled somehow, but to listen to more bridge learning events. It turns out that the bridge driver does learn in software from all inbound frames, in __br_handle_local_finish. A proper SWITCHDEV_FDB_ADD_TO_DEVICE notification is emitted for the addresses serviced by the bridge on 'foreign' interfaces. The software bridge also does the right thing on migration, by notifying that the old entry is deleted, so that does not need to be special-cased in DSA. When it is deleted, we just need to delete our static FDB entry towards the CPU too, and wait. The problem is that DSA currently only cares about SWITCHDEV_FDB_ADD_TO_DEVICE events received on its own interfaces, such as static FDB entries. Luckily we can change that, and DSA can listen to all switchdev FDB add/del events in the system and figure out if those events were emitted by a bridge that spans at least one of DSA's own ports. In case that is true, DSA will also offload that address towards its own CPU port, in the eventuality that there might be bridge clients attached to the DSA switch who want to talk to the station connected to the foreign interface. In terms of implementation, we need to keep the fdb_info->added_by_user check for the case where the switchdev event was targeted directly at a DSA switch port. But we don't need to look at that flag for snooped events. So the check is currently too late, we need to move it earlier. This also simplifies the code a bit, since we avoid uselessly allocating and freeing switchdev_work. We could probably do some improvements in the future. For example, multi-bridge support is rudimentary at the moment. If there are two bridges spanning a DSA switch's ports, and both of them need to service the same MAC address, then what will happen is that the migration of one of those stations will trigger the deletion of the FDB entry from the CPU port while it is still used by other bridge. That could be improved with reference counting but is left for another time. This behavior needs to be enabled at driver level by setting ds->assisted_learning_on_cpu_port = true. This is because we don't want to inflict a potential performance penalty (accesses through MDIO/I2C/SPI are expensive) to hardware that really doesn't need it because address learning on the CPU port works there. Reported-by: DENG Qingfang Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn --- Changes in v4: None. Changes in v3: - s/learning_broken/assisted_learning/ - don't call dev_hold unless it's a DSA slave interface, to avoid broken refcounting Changes in v2: Made the behavior conditional. include/net/dsa.h | 5 ++++ net/dsa/slave.c | 66 +++++++++++++++++++++++++++++++++++++++-------- 2 files changed, 60 insertions(+), 11 deletions(-) diff --git a/include/net/dsa.h b/include/net/dsa.h index 4e60d2610f20..6b74690bd8d4 100644 --- a/include/net/dsa.h +++ b/include/net/dsa.h @@ -319,6 +319,11 @@ struct dsa_switch { */ bool untag_bridge_pvid; + /* Let DSA manage the FDB entries towards the CPU, based on the + * software bridge database. + */ + bool assisted_learning_on_cpu_port; + /* In case vlan_filtering_is_global is set, the VLAN awareness state * should be retrieved from here and not from the per-port settings. */ diff --git a/net/dsa/slave.c b/net/dsa/slave.c index 37dffe5bc46f..456576f75a50 100644 --- a/net/dsa/slave.c +++ b/net/dsa/slave.c @@ -2109,6 +2109,28 @@ static void dsa_slave_switchdev_event_work(struct work_struct *work) dev_put(dp->slave); } +static int dsa_lower_dev_walk(struct net_device *lower_dev, + struct netdev_nested_priv *priv) +{ + if (dsa_slave_dev_check(lower_dev)) { + priv->data = (void *)netdev_priv(lower_dev); + return 1; + } + + return 0; +} + +static struct dsa_slave_priv *dsa_slave_dev_lower_find(struct net_device *dev) +{ + struct netdev_nested_priv priv = { + .data = NULL, + }; + + netdev_walk_all_lower_dev_rcu(dev, dsa_lower_dev_walk, &priv); + + return (struct dsa_slave_priv *)priv.data; +} + /* Called under rcu_read_lock() */ static int dsa_slave_switchdev_event(struct notifier_block *unused, unsigned long event, void *ptr) @@ -2127,10 +2149,37 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused, return notifier_from_errno(err); case SWITCHDEV_FDB_ADD_TO_DEVICE: case SWITCHDEV_FDB_DEL_TO_DEVICE: - if (!dsa_slave_dev_check(dev)) - return NOTIFY_DONE; + fdb_info = ptr; - dp = dsa_slave_to_port(dev); + if (dsa_slave_dev_check(dev)) { + if (!fdb_info->added_by_user) + return NOTIFY_OK; + + dp = dsa_slave_to_port(dev); + } else { + /* Snoop addresses learnt on foreign interfaces + * bridged with us, for switches that don't + * automatically learn SA from CPU-injected traffic + */ + struct net_device *br_dev; + struct dsa_slave_priv *p; + + br_dev = netdev_master_upper_dev_get_rcu(dev); + if (!br_dev) + return NOTIFY_DONE; + + if (!netif_is_bridge_master(br_dev)) + return NOTIFY_DONE; + + p = dsa_slave_dev_lower_find(br_dev); + if (!p) + return NOTIFY_DONE; + + dp = p->dp->cpu_dp; + + if (!dp->ds->assisted_learning_on_cpu_port) + return NOTIFY_DONE; + } if (!dp->ds->ops->port_fdb_add || !dp->ds->ops->port_fdb_del) return NOTIFY_DONE; @@ -2145,18 +2194,13 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused, switchdev_work->port = dp->index; switchdev_work->event = event; - fdb_info = ptr; - - if (!fdb_info->added_by_user) { - kfree(switchdev_work); - return NOTIFY_OK; - } - ether_addr_copy(switchdev_work->addr, fdb_info->addr); switchdev_work->vid = fdb_info->vid; - dev_hold(dev); + /* Hold a reference on the slave for dsa_fdb_offload_notify */ + if (dsa_is_user_port(dp->ds, dp->index)) + dev_hold(dev); dsa_schedule_work(&switchdev_work->work); break; default: From patchwork Wed Jan 6 09:51:36 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vladimir Oltean X-Patchwork-Id: 12001229 X-Patchwork-Delegate: kuba@kernel.org Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 10B0BC433DB for ; Wed, 6 Jan 2021 09:54:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C4DB12310D for ; Wed, 6 Jan 2021 09:54:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727050AbhAFJxQ (ORCPT ); Wed, 6 Jan 2021 04:53:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727024AbhAFJxP (ORCPT ); Wed, 6 Jan 2021 04:53:15 -0500 Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E78DBC06135E; Wed, 6 Jan 2021 01:52:17 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id b2so3889252edm.3; Wed, 06 Jan 2021 01:52:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=EJz2f0BPU/V/WA7rRceP314TuPjibKG/K1RbisBajTo=; b=rQffNnMRM7oY9+l+SpdWettB2i1OKHz8Lz3g09zgPf3ec3ndhAnOqlOVCtp5BKqPAM GM31b+hc3zuVHBbAcpLec7UZYKcM3na7OcLpXOWW7Ra6EihpvYf2h2CwjUyaPkQRr4AW yNSOkgVn0HHWvWLHPGek3GC2pYiNMpP7dOPvo1nXCjHlKomgd1Znxc7FDR/AJOLuzZvp cvzV9WijdJ9epII9ZtODKpZytTr1MFouAn4P5mbxZ/MPaeZ1e3KkBgphqyTQpIgyDnR4 1TGGWGRYZ+pj2w9/lL/ezmKT3iKMFaldyoxCcjtzkOJxVHrKmmlmCriikJbypo4rEfD4 OKhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=EJz2f0BPU/V/WA7rRceP314TuPjibKG/K1RbisBajTo=; b=C2tyYiPoBpcdQK4sRkH6/oslU/bkj9+63zXvrs+UZ58u3Ypl8UbtcMF2TIUbRHexQj gGnMMZb5D/ytN9Ku9Y0ikbe/F//+usupwQzjquP8YuEVSLY0n7jykd7xatkftYD1FOEU IngzLsl34XC3OxeFCDBbYUaiUcE2vUv3pWsZ8MXNa6+DkLm56hat4WadbSE7isSWTB3x FW5lpfTANxBLqe0W0ZQAu7F/FqZCNQziUbu2/JqeGxO0B/6ykHd31DCrARK1SIQ2FyZP lztXXUZmuu0RR+upVYw/632/7SW61lfvabFQbW+crcwDegrG+vt7HKECR1Ht44QQAagC mefQ== X-Gm-Message-State: AOAM530vNvVFCjzFp1Q6FC/LVeuYrKCpim6F1kcMJrIbvW9BavEc4pC5 OoLAPfKblJzmDK2RULQSnus= X-Google-Smtp-Source: ABdhPJwxu5waLfll8PJNcf8kYlI8DCoNBnS83NsaQszhFl33Rn+Pdbaw+WiWrPjr6CzxniORyULxNQ== X-Received: by 2002:a50:d604:: with SMTP id x4mr3468939edi.64.1609926736645; Wed, 06 Jan 2021 01:52:16 -0800 (PST) Received: from localhost.localdomain (5-12-227-87.residential.rdsnet.ro. [5.12.227.87]) by smtp.gmail.com with ESMTPSA id n8sm1019587eju.33.2021.01.06.01.52.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 Jan 2021 01:52:16 -0800 (PST) From: Vladimir Oltean To: Andrew Lunn , Vivien Didelot , Florian Fainelli , Jakub Kicinski , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, Roopa Prabhu , Nikolay Aleksandrov , "David S. Miller" Cc: DENG Qingfang , Tobias Waldekranz , Marek Behun , Russell King - ARM Linux admin , Alexandra Winter , Jiri Pirko , Ido Schimmel , Claudiu Manoil , UNGLinuxDriver@microchip.com Subject: [PATCH v4 net-next 7/7] net: dsa: ocelot: request DSA to fix up lack of address learning on CPU port Date: Wed, 6 Jan 2021 11:51:36 +0200 Message-Id: <20210106095136.224739-8-olteanv@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210106095136.224739-1-olteanv@gmail.com> References: <20210106095136.224739-1-olteanv@gmail.com> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: kuba@kernel.org From: Vladimir Oltean Given the following setup: ip link add br0 type bridge ip link set eno0 master br0 ip link set swp0 master br0 ip link set swp1 master br0 ip link set swp2 master br0 ip link set swp3 master br0 Currently, packets received on a DSA slave interface (such as swp0) which should be routed by the software bridge towards a non-switch port (such as eno0) are also flooded towards the other switch ports (swp1, swp2, swp3) because the destination is unknown to the hardware switch. This patch addresses the issue by monitoring the addresses learnt by the software bridge on eno0, and adding/deleting them as static FDB entries on the CPU port accordingly. Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn --- Changes in v4: None. Changes in v3: s/learning_broken/assisted_learning/ Changes in v2: Patch is new. drivers/net/dsa/ocelot/felix.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/dsa/ocelot/felix.c b/drivers/net/dsa/ocelot/felix.c index 7dc230677b78..90c3c76f21b2 100644 --- a/drivers/net/dsa/ocelot/felix.c +++ b/drivers/net/dsa/ocelot/felix.c @@ -629,6 +629,7 @@ static int felix_setup(struct dsa_switch *ds) ds->mtu_enforcement_ingress = true; ds->configure_vlan_while_not_filtering = true; + ds->assisted_learning_on_cpu_port = true; return 0; }