[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210226181250.4km4xf4ntxkts6y7@skbuf>
Date: Fri, 26 Feb 2021 20:12:50 +0200
From: Vladimir Oltean <olteanv@...il.com>
To: Tobias Waldekranz <tobias@...dekranz.com>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
Florian Fainelli <f.fainelli@...il.com>,
Vivien Didelot <vivien.didelot@...il.com>,
Jiri Pirko <jiri@...nulli.us>,
Ido Schimmel <idosch@...sch.org>,
DENG Qingfang <dqfext@...il.com>,
George McCollister <george.mccollister@...il.com>,
Horatiu Vultur <horatiu.vultur@...rochip.com>,
Kurt Kanzenbach <kurt@...utronix.de>
Subject: Re: [RFC PATCH net-next 02/12] Documentation: networking: dsa:
rewrite chapter about tagging protocol
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.
Powered by blists - more mailing lists