Re: [RFC PATCH net-next 02/12] Documentation: networking: dsa: rewrite chapter about tagging protocol

From: Tobias Waldekranz <tobias@waldekranz.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: netdev@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Jiri Pirko <jiri@resnulli.us>, Ido Schimmel <idosch@idosch.org>,
	DENG Qingfang <dqfext@gmail.com>,
	George McCollister <george.mccollister@gmail.com>,
	Horatiu Vultur <horatiu.vultur@microchip.com>,
	Kurt Kanzenbach <kurt@linutronix.de>
Subject: Re: [RFC PATCH net-next 02/12] Documentation: networking: dsa: rewrite chapter about tagging protocol
Date: Sat, 27 Feb 2021 00:19:29 +0100	[thread overview]
Message-ID: <87h7lyquwu.fsf@waldekranz.com> (raw)
In-Reply-To: <20210226181250.4km4xf4ntxkts6y7@skbuf>

On Fri, Feb 26, 2021 at 20:12, Vladimir Oltean <olteanv@gmail.com> wrote:
> On Thu, Feb 25, 2021 at 09:29:21PM +0100, Tobias Waldekranz wrote:
>> This is not strictly true for mv88e6xxx. The connection between the tree
>> and the CPU may use Ethertyped DSA tags, while inter-switch links use
>> regular DSA tags.
>> 
>> However, I think it is better to keep this definition short, as it is
>> "true enough" :)
>
> What is the use case for this? Build a DSA tree out of old switches
> which support only DSA, plus new switches which support both DSA and
> EDSA, and have the host CPU see only EDSA, with the cascaded switches
> playing the role of DSA->EDSA adapters for the leaf switches?
> Is there any point in doing this? If it ever becomes necessary to
> support this, can't we just say that you should configure your entire
> DSA tree to use either DSA or EDSA, whichever happens to be supported
> across all devices? We already have support for changing the tag
> protocol, mv88e6xxx should implement it, then we could add some logic
> somewhere to scan for the DSA tree at probe time and figure out a common
> denominator.

This is already supported today. Cascade ports are _always_ set to
DSA. There are 2 reasons for that that I can think of:

1. It is the lowest common denominator, supported by all devices, so it
   makes for an easy algorithm.

2. It adds the minimum amount of overhead (4 bytes less than EDSA). If
   you are saturating your cascade link with 64B packets, that has quite
   an impact on your maximum pps.

As for why you would choose EDSA over DSA for connecting to the CPU: I
would say that on Linux with the DSA driver there is no reason, we could
probably drop the support altogether.

Before /sys/class/net/*/dsa/tagging, tcpdump could produce better
output, but that is no longer an issue.

The other advantage with EDSA is that you can use it for control traffic
(TO_CPU), while receiving data traffic (FORWARD) either untagged
Q-tagged. So you could use more of your NIC's offloads for example. But
this does not really work with the switchdev model as there is no
separation of control/data.

Though, now that I think about it, maybe we _can_ to that with the
filter method I just learned about from reading your excellent
documentation :)

Whether we want to is another question, but my guess is that things like
L3 forwarding performance could improve quite a bit, since there is less
memmoving around of L2 headers.