From: Vladimir Oltean <olteanv@gmail.com> To: Andrew Lunn <andrew@lunn.ch>, Vivien Didelot <vivien.didelot@gmail.com>, Florian Fainelli <f.fainelli@gmail.com>, Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, Roopa Prabhu <roopa@nvidia.com>, Nikolay Aleksandrov <nikolay@nvidia.com>, "David S. Miller" <davem@davemloft.net> Cc: DENG Qingfang <dqfext@gmail.com>, Tobias Waldekranz <tobias@waldekranz.com>, Marek Behun <marek.behun@nic.cz>, Russell King - ARM Linux admin <linux@armlinux.org.uk>, Alexandra Winter <wintera@linux.ibm.com>, Jiri Pirko <jiri@resnulli.us>, Ido Schimmel <idosch@idosch.org>, Claudiu Manoil <claudiu.manoil@nxp.com>, 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 [thread overview] Message-ID: <20210106095136.224739-8-olteanv@gmail.com> (raw) In-Reply-To: <20210106095136.224739-1-olteanv@gmail.com> From: Vladimir Oltean <vladimir.oltean@nxp.com> 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 <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> --- 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; } -- 2.25.1
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <olteanv@gmail.com> To: Andrew Lunn <andrew@lunn.ch>, Vivien Didelot <vivien.didelot@gmail.com>, Florian Fainelli <f.fainelli@gmail.com>, Jakub Kicinski <kuba@kernel.org>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, bridge@lists.linux-foundation.org, Roopa Prabhu <roopa@nvidia.com>, Nikolay Aleksandrov <nikolay@nvidia.com>, "David S. Miller" <davem@davemloft.net> Cc: Jiri Pirko <jiri@resnulli.us>, Alexandra Winter <wintera@linux.ibm.com>, Ido Schimmel <idosch@idosch.org>, Russell King - ARM Linux admin <linux@armlinux.org.uk>, Marek Behun <marek.behun@nic.cz>, DENG Qingfang <dqfext@gmail.com>, Claudiu Manoil <claudiu.manoil@nxp.com>, UNGLinuxDriver@microchip.com, Tobias Waldekranz <tobias@waldekranz.com> Subject: [Bridge] [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 [thread overview] Message-ID: <20210106095136.224739-8-olteanv@gmail.com> (raw) In-Reply-To: <20210106095136.224739-1-olteanv@gmail.com> From: Vladimir Oltean <vladimir.oltean@nxp.com> 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 <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> --- 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; } -- 2.25.1
next prev parent reply other threads:[~2021-01-06 9:54 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-06 9:51 [PATCH v4 net-next 0/7] Offload software learnt bridge addresses to DSA Vladimir Oltean 2021-01-06 9:51 ` [Bridge] " Vladimir Oltean 2021-01-06 9:51 ` [PATCH v4 net-next 1/7] net: bridge: notify switchdev of disappearance of old FDB entry upon migration Vladimir Oltean 2021-01-06 9:51 ` [Bridge] " Vladimir Oltean 2021-01-06 17:43 ` Florian Fainelli 2021-01-06 17:43 ` [Bridge] " Florian Fainelli 2021-01-06 9:51 ` [PATCH v4 net-next 2/7] net: dsa: be louder when a non-legacy FDB operation fails Vladimir Oltean 2021-01-06 9:51 ` [Bridge] " Vladimir Oltean 2021-01-06 17:44 ` Florian Fainelli 2021-01-06 17:44 ` [Bridge] " Florian Fainelli 2021-01-06 9:51 ` [PATCH v4 net-next 3/7] net: dsa: don't use switchdev_notifier_fdb_info in dsa_switchdev_event_work Vladimir Oltean 2021-01-06 9:51 ` [Bridge] " Vladimir Oltean 2021-01-06 9:51 ` [PATCH v4 net-next 4/7] net: dsa: move switchdev event implementation under the same switch/case statement Vladimir Oltean 2021-01-06 9:51 ` [Bridge] " Vladimir Oltean 2021-01-06 9:51 ` [PATCH v4 net-next 5/7] net: dsa: exit early in dsa_slave_switchdev_event if we can't program the FDB Vladimir Oltean 2021-01-06 9:51 ` [Bridge] " Vladimir Oltean 2021-01-06 9:51 ` [PATCH v4 net-next 6/7] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors Vladimir Oltean 2021-01-06 9:51 ` [Bridge] [PATCH v4 net-next 6/7] net: dsa: listen for SWITCHDEV_{FDB, DEL}_ADD_TO_DEVICE " Vladimir Oltean 2021-01-06 9:51 ` Vladimir Oltean [this message] 2021-01-06 9:51 ` [Bridge] [PATCH v4 net-next 7/7] net: dsa: ocelot: request DSA to fix up lack of address learning on CPU port Vladimir Oltean 2021-01-07 23:50 ` [PATCH v4 net-next 0/7] Offload software learnt bridge addresses to DSA patchwork-bot+netdevbpf 2021-01-07 23:50 ` [Bridge] " patchwork-bot+netdevbpf
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20210106095136.224739-8-olteanv@gmail.com \ --to=olteanv@gmail.com \ --cc=UNGLinuxDriver@microchip.com \ --cc=andrew@lunn.ch \ --cc=bridge@lists.linux-foundation.org \ --cc=claudiu.manoil@nxp.com \ --cc=davem@davemloft.net \ --cc=dqfext@gmail.com \ --cc=f.fainelli@gmail.com \ --cc=idosch@idosch.org \ --cc=jiri@resnulli.us \ --cc=kuba@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux@armlinux.org.uk \ --cc=marek.behun@nic.cz \ --cc=netdev@vger.kernel.org \ --cc=nikolay@nvidia.com \ --cc=roopa@nvidia.com \ --cc=tobias@waldekranz.com \ --cc=vivien.didelot@gmail.com \ --cc=wintera@linux.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.