Re: [RFC PATCH net-next 02/12] Documentation: networking: dsa: rewrite chapter about tagging protocol
From: Tobias Waldekranz <tobias@waldekranz.com>
Date: 2021-02-26 23:20:15
On Fri, Feb 26, 2021 at 20:12, Vladimir Oltean [off-list ref] wrote:
On Thu, Feb 25, 2021 at 09:29:21PM +0100, Tobias Waldekranz wrote:quoted
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.