All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org
Cc: Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Vladimir Oltean <vladimir.oltean@nxp.com>,
	UNGLinuxDriver@microchip.com
Subject: [PATCH v7 net-next 07/11] net: dsa: keep a copy of the tagging protocol in the DSA switch tree
Date: Tue, 26 Jan 2021 00:03:29 +0200	[thread overview]
Message-ID: <20210125220333.1004365-8-olteanv@gmail.com> (raw)
In-Reply-To: <20210125220333.1004365-1-olteanv@gmail.com>

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

Cascading DSA switches can be done multiple ways. There is the brute
force approach / tag stacking, where one upstream switch, located
between leaf switches and the host Ethernet controller, will just
happily transport the DSA header of those leaf switches as payload.
For this kind of setups, DSA works without any special kind of treatment
compared to a single switch - they just aren't aware of each other.
Then there's the approach where the upstream switch understands the tags
it transports from its leaves below, as it doesn't push a tag of its own,
but it routes based on the source port & switch id information present
in that tag (as opposed to DMAC & VID) and it strips the tag when
egressing a front-facing port. Currently only Marvell implements the
latter, and Marvell DSA trees contain only Marvell switches.

So it is safe to say that DSA trees already have a single tag protocol
shared by all switches, and in fact this is what makes the switches able
to understand each other.

It's time to make this official and enforce it (yes, this also means we
won't have any "switch understands tag to some extent but is not able to
speak it" hardware oddities that we'll support in the future).

This is needed due to the imminent introduction of the dsa_switch_ops::
{set,del}_tag_protocol driver API. When that is introduced, we'll have
to notify switches of the tagging protocol that they're configured to
use, even at probe and remove time. Currently the tag_ops structure
pointer is held only for CPU ports. But there are switches which don't
have CPU ports and nonetheless still need to be configured. These would
be Marvell leaf switches whose upstream port is just a DSA link. How do
we inform these of their tagging protocol setup/deletion?

One answer to the above would be: iterate through the DSA switch tree's
ports once, list the CPU ports, get their tag_ops, then iterate again
now that we have it, and notify everybody of that tag_ops. But what to
do if conflicts appear between one cpu_dp->tag_ops and another? There's
no escaping the fact that it makes no sense to have multiple tag_ops in
the same dst.

Ease our work and just keep the master copy of the tag_ops inside the
struct dsa_switch_tree. Note that reference counting the tagger module
driver still happens for each CPU port that uses that tagging protocol.

There are many places in the data path that access master->dsa_ptr->tag_ops
and we would introduce unnecessary performance penalty going through yet
another indirection, so keep those right where they are.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
Changes in v7:
Patch is new.

 include/net/dsa.h | 7 ++++++-
 net/dsa/dsa2.c    | 6 ++++++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/include/net/dsa.h b/include/net/dsa.h
index 2f5435d3d1db..b8af1d6c879a 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -140,6 +140,9 @@ struct dsa_switch_tree {
 	/* Has this tree been applied to the hardware? */
 	bool setup;
 
+	/* Tagging protocol operations */
+	const struct dsa_device_ops *tag_ops;
+
 	/*
 	 * Configuration data for the platform device that owns
 	 * this dsa switch tree instance.
@@ -225,7 +228,9 @@ struct dsa_port {
 		struct net_device *slave;
 	};
 
-	/* CPU port tagging operations used by master or slave devices */
+	/* Copy of the tagging protocol operations, for quicker access
+	 * in the data path. Valid only for the CPU ports.
+	 */
 	const struct dsa_device_ops *tag_ops;
 
 	/* Copies for faster access in master receive hot path */
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 2953d0c1c7bc..42f22955e111 100644
--- a/net/dsa/dsa2.c
+++ b/net/dsa/dsa2.c
@@ -1026,6 +1026,12 @@ static int dsa_port_parse_cpu(struct dsa_port *dp, struct net_device *master)
 
 	dp->master = master;
 	dp->type = DSA_PORT_TYPE_CPU;
+	if (dst->tag_ops && dst->tag_ops != tag_ops) {
+		dev_err(ds->dev,
+			"A DSA switch tree can have only one tagging protocol\n");
+		return -EINVAL;
+	}
+	dst->tag_ops = tag_ops;
 	dp->filter = tag_ops->filter;
 	dp->rcv = tag_ops->rcv;
 	dp->tag_ops = tag_ops;
-- 
2.25.1


  parent reply	other threads:[~2021-01-25 22:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-25 22:03 [PATCH v7 net-next 00/11] tag_8021q for Ocelot switches Vladimir Oltean
2021-01-25 22:03 ` [PATCH v7 net-next 01/11] net: dsa: tag_8021q: add helpers to deduce whether a VLAN ID is RX or TX VLAN Vladimir Oltean
2021-01-25 22:03 ` [PATCH v7 net-next 02/11] net: mscc: ocelot: export VCAP structures to include/soc/mscc Vladimir Oltean
2021-01-25 22:03 ` [PATCH v7 net-next 03/11] net: mscc: ocelot: store a namespaced VCAP filter ID Vladimir Oltean
2021-01-25 22:03 ` [PATCH v7 net-next 04/11] net: mscc: ocelot: reapply bridge forwarding mask on bonding join/leave Vladimir Oltean
2021-01-25 22:03 ` [PATCH v7 net-next 05/11] net: mscc: ocelot: don't use NPI tag prefix for the CPU port module Vladimir Oltean
2021-01-25 22:03 ` [PATCH v7 net-next 06/11] net: dsa: document the existing switch tree notifiers and add a new one Vladimir Oltean
2021-01-25 22:03 ` Vladimir Oltean [this message]
2021-01-25 22:03 ` [PATCH v7 net-next 08/11] net: dsa: allow changing the tag protocol via the "tagging" device attribute Vladimir Oltean
2021-01-28  1:30   ` Jakub Kicinski
2021-01-28  1:51     ` Florian Fainelli
2021-01-28 20:07     ` Vladimir Oltean
2021-01-29  2:14       ` Jakub Kicinski
2021-01-25 22:03 ` [PATCH v7 net-next 09/11] net: dsa: felix: convert to the new .{set,del}_tag_protocol DSA API Vladimir Oltean
2021-01-25 22:03 ` [PATCH v7 net-next 10/11] net: dsa: add a second tagger for Ocelot switches based on tag_8021q Vladimir Oltean
2021-01-25 22:03 ` [PATCH v7 net-next 11/11] net: dsa: felix: perform switch setup for tag_8021q 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:
  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=20210125220333.1004365-8-olteanv@gmail.com \
    --to=olteanv@gmail.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --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 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.