Netdev Archive on
help / color / mirror / Atom feed
From: Vladimir Oltean <>
To:, Jakub Kicinski <>,
	"David S. Miller" <>
Cc: Andrew Lunn <>,
	Florian Fainelli <>,
	Vivien Didelot <>,
	Vladimir Oltean <>
Subject: [PATCH v2 net-next 8/8] net: dsa: sja1105: enable address learning on cascade ports
Date: Wed,  4 Aug 2021 16:16:22 +0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Right now, address learning is disabled on DSA ports, which means that a
packet received over a DSA port from a cross-chip switch will be flooded
to unrelated ports.

It is desirable to eliminate that, but for that we need a breakdown of
the possibilities for the sja1105 driver. A DSA port can be:

- a downstream-facing cascade port. This is simple because it will
  always receive packets from a downstream switch, and there should be
  no other route to reach that downstream switch in the first place,
  which means it should be safe to learn that MAC address towards that

- an upstream-facing cascade port. This receives packets either:
  * autonomously forwarded by an upstream switch (and therefore these
    packets belong to the data plane of a bridge, so address learning
    should be ok), or
  * injected from the CPU. This deserves further discussion, as normally,
    an upstream-facing cascade port is no different than the CPU port
    itself. But with "H" topologies (a DSA link towards a switch that
    has its own CPU port), these are more "laterally-facing" cascade
    ports than they are "upstream-facing". Here, there is a risk that
    the port might learn the host addresses on the wrong port (on the
    DSA port instead of on its own CPU port), but this is solved by
    DSA's RX filtering infrastructure, which installs the host addresses
    as static FDB entries on the CPU port of all switches in a "H" tree.
    So even if there will be an attempt from the switch to migrate the
    FDB entry from the CPU port to the laterally-facing cascade port, it
    will fail to do that, because the FDB entry that already exists is
    static and cannot migrate. So address learning should be safe for
    this configuration too.

Ok, so what about other MAC addresses coming from the host, not
necessarily the bridge local FDB entries? What about MAC addresses
dynamically learned on foreign interfaces, isn't there a risk that
cascade ports will learn these entries dynamically when they are
supposed to be delivered towards the CPU port? Well, that is correct,
and this is why we also need to enable the assisted learning feature, to
snoop for these addresses and write them to hardware as static FDB
entries towards the CPU, to make the switch's learning process on the
cascade ports ineffective for them. With assisted learning enabled, the
hardware learning on the CPU port must be disabled.

Signed-off-by: Vladimir Oltean <>
 drivers/net/dsa/sja1105/sja1105_main.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dsa/sja1105/sja1105_main.c b/drivers/net/dsa/sja1105/sja1105_main.c
index b3b5ae3ef408..f13a6766dd41 100644
--- a/drivers/net/dsa/sja1105/sja1105_main.c
+++ b/drivers/net/dsa/sja1105/sja1105_main.c
@@ -199,9 +199,13 @@ static int sja1105_init_mac_settings(struct sja1105_private *priv)
 		mac[i] = default_mac;
 		/* Let sja1105_bridge_stp_state_set() keep address learning
-		 * enabled for the CPU port.
+		 * enabled for the DSA ports. CPU ports use software-assisted
+		 * learning to ensure that only FDB entries belonging to the
+		 * bridge are learned, and that they are learned towards all
+		 * CPU ports in a cross-chip topology if multiple CPU ports
+		 * exist.
-		if (dsa_is_cpu_port(ds, i))
+		if (dsa_is_dsa_port(ds, i))
 			priv->learn_ena |= BIT(i);
@@ -2509,6 +2513,7 @@ static int sja1105_setup(struct dsa_switch *ds)
 	ds->num_tx_queues = SJA1105_NUM_TC;
 	ds->mtu_enforcement_ingress = true;
+	ds->assisted_learning_on_cpu_port = true;
 	rc = sja1105_devlink_setup(ds);
 	if (rc < 0)

  parent reply	other threads:[~2021-08-04 13:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-04 13:16 [PATCH v2 net-next 0/8] NXP SJA1105 driver support for "H" switch topologies Vladimir Oltean
2021-08-04 13:16 ` [PATCH v2 net-next 1/8] net: dsa: rename teardown_default_cpu to teardown_cpu_ports Vladimir Oltean
2021-08-04 13:16 ` [PATCH v2 net-next 2/8] net: dsa: give preference to local CPU ports Vladimir Oltean
2021-08-04 13:16 ` [PATCH v2 net-next 3/8] net: dsa: sja1105: configure the cascade ports based on topology Vladimir Oltean
2021-08-04 13:16 ` [PATCH v2 net-next 4/8] net: dsa: sja1105: manage the forwarding domain towards DSA ports Vladimir Oltean
2021-08-04 13:16 ` [PATCH v2 net-next 5/8] net: dsa: sja1105: manage VLANs on cascade ports Vladimir Oltean
2021-08-04 13:16 ` [PATCH v2 net-next 6/8] net: dsa: sja1105: increase MTU to account for VLAN header on DSA ports Vladimir Oltean
2021-08-04 13:16 ` [PATCH v2 net-next 7/8] net: dsa: sja1105: suppress TX packets from looping back in "H" topologies Vladimir Oltean
2021-08-04 13:16 ` Vladimir Oltean [this message]
2021-08-04 13:19 ` [PATCH v2 net-next 0/8] NXP SJA1105 driver support for "H" switch topologies Vladimir Oltean

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \
    --subject='Re: [PATCH v2 net-next 8/8] net: dsa: sja1105: enable address learning on cascade ports' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).