Ethernet Bridge development
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>
Cc: Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jiri Pirko <jiri@resnulli.us>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	bridge@lists.linux-foundation.org,
	Ido Schimmel <idosch@idosch.org>,
	Nikolay Aleksandrov <nikolay@nvidia.com>,
	Roopa Prabhu <roopa@nvidia.com>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Tobias Waldekranz <tobias@waldekranz.com>
Subject: [Bridge] [PATCH v5 net-next 13/15] net: dsa: include fdb entries pointing to bridge in the host fdb list
Date: Tue, 29 Jun 2021 17:06:56 +0300	[thread overview]
Message-ID: <20210629140658.2510288-14-olteanv@gmail.com> (raw)
In-Reply-To: <20210629140658.2510288-1-olteanv@gmail.com>

From: Vladimir Oltean <vladimir.oltean@nxp.com>

The bridge supports a legacy way of adding local (non-forwarded) FDB
entries, which works on an individual port basis:

bridge fdb add dev swp0 00:01:02:03:04:05 master local

As well as a new way, added by Roopa Prabhu in commit 3741873b4f73
("bridge: allow adding of fdb entries pointing to the bridge device"):

bridge fdb add dev br0 00:01:02:03:04:05 self local

The two commands are functionally equivalent, except that the first one
produces an entry with fdb->dst == swp0, and the other an entry with
fdb->dst == NULL. The confusing part, though, is that even if fdb->dst
is swp0 for the 'local on port' entry, that destination is not used.

Nonetheless, the idea is that the bridge has reference counting for
local entries, and local entries pointing towards the bridge are still
'as local' as local entries for a port.

The bridge adds the MAC addresses of the interfaces automatically as
FDB entries with is_local=1. For the MAC address of the ports, fdb->dst
will be equal to the port, and for the MAC address of the bridge,
fdb->dst will point towards the bridge (i.e. be NULL). Therefore, if the
MAC address of the bridge is not inherited from either of the physical
ports, then we must explicitly catch local FDB entries emitted towards
the br0, otherwise we'll miss the MAC address of the bridge (and, of
course, any entry with 'bridge add dev br0 ... self local').

Co-developed-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
v4->v5: none

 net/dsa/slave.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index d006bd04f84a..a7b5d2a41472 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -2415,7 +2415,11 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused,
 			struct net_device *br_dev;
 			struct dsa_slave_priv *p;
 
-			br_dev = netdev_master_upper_dev_get_rcu(dev);
+			if (netif_is_bridge_master(dev))
+				br_dev = dev;
+			else
+				br_dev = netdev_master_upper_dev_get_rcu(dev);
+
 			if (!br_dev)
 				return NOTIFY_DONE;
 
@@ -2443,8 +2447,13 @@ static int dsa_slave_switchdev_event(struct notifier_block *unused,
 			 * LAG we don't want to send traffic to the CPU, the
 			 * other ports bridged with the LAG should be able to
 			 * autonomously forward towards it.
+			 * On the other hand, if the address is local
+			 * (therefore not learned) then we want to trap it to
+			 * the CPU regardless of whether the interface it
+			 * belongs to is offloaded or not.
 			 */
-			if (dsa_tree_offloads_bridge_port(dp->ds->dst, dev))
+			if (dsa_tree_offloads_bridge_port(dp->ds->dst, dev) &&
+			    !fdb_info->is_local)
 				return NOTIFY_DONE;
 		}
 
-- 
2.25.1


  parent reply	other threads:[~2021-06-29 14:06 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-29 14:06 [Bridge] [PATCH v5 net-next 00/15] RX filtering in DSA Vladimir Oltean
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 01/15] net: bridge: use READ_ONCE() and WRITE_ONCE() compiler barriers for fdb->dst Vladimir Oltean
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 02/15] net: bridge: switchdev: send FDB notifications for host addresses Vladimir Oltean
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 03/15] net: bridge: allow br_fdb_replay to be called for the bridge device Vladimir Oltean
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 04/15] net: dsa: delete dsa_legacy_fdb_add and dsa_legacy_fdb_del Vladimir Oltean
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 05/15] net: dsa: introduce dsa_is_upstream_port and dsa_switch_is_upstream_of Vladimir Oltean
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 06/15] net: dsa: introduce a separate cross-chip notifier type for host MDBs Vladimir Oltean
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 07/15] net: dsa: reference count the MDB entries at the cross-chip notifier level Vladimir Oltean
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 08/15] net: dsa: introduce a separate cross-chip notifier type for host FDBs Vladimir Oltean
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 09/15] net: dsa: reference count the FDB addresses at the cross-chip notifier level Vladimir Oltean
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 10/15] net: dsa: install the host MDB and FDB entries in the master's RX filter Vladimir Oltean
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 11/15] net: dsa: sync static FDB entries on foreign interfaces to hardware Vladimir Oltean
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 12/15] net: dsa: include bridge addresses which are local in the host fdb list Vladimir Oltean
2021-06-29 14:06 ` Vladimir Oltean [this message]
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 14/15] net: dsa: ensure during dsa_fdb_offload_notify that dev_hold and dev_put are on the same dev Vladimir Oltean
2021-06-29 14:06 ` [Bridge] [PATCH v5 net-next 15/15] net: dsa: replay the local bridge FDB entries pointing to the bridge dev too Vladimir Oltean
2021-06-29 17:50 ` [Bridge] [PATCH v5 net-next 00/15] RX filtering in DSA patchwork-bot+netdevbpf
2021-06-29 18:52 ` David Miller
2021-06-29 18:58   ` Vladimir Oltean
2021-06-29 19:09     ` Vladimir Oltean
2021-06-29 22:08       ` David Miller

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=20210629140658.2510288-14-olteanv@gmail.com \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@idosch.org \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@nvidia.com \
    --cc=roopa@nvidia.com \
    --cc=tobias@waldekranz.com \
    --cc=vivien.didelot@gmail.com \
    --cc=vladimir.oltean@nxp.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox