From: Vladimir Oltean <olteanv@gmail.com>
To: Tobias Waldekranz <tobias@waldekranz.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: Fri, 26 Feb 2021 20:12:50 +0200 [thread overview]
Message-ID: <20210226181250.4km4xf4ntxkts6y7@skbuf> (raw)
In-Reply-To: <87y2fbrivy.fsf@waldekranz.com>
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.
next prev parent reply other threads:[~2021-02-26 18:13 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-21 21:33 [RFC PATCH net-next 00/12] Documentation updates for switchdev and DSA Vladimir Oltean
2021-02-21 21:33 ` [RFC PATCH net-next 01/12] Documentation: networking: update the graphical representation Vladimir Oltean
2021-02-22 5:06 ` Florian Fainelli
2021-02-25 19:29 ` Tobias Waldekranz
2021-02-21 21:33 ` [RFC PATCH net-next 02/12] Documentation: networking: dsa: rewrite chapter about tagging protocol Vladimir Oltean
2021-02-22 5:12 ` Florian Fainelli
2021-02-24 23:54 ` Andrew Lunn
2021-02-25 20:29 ` Tobias Waldekranz
2021-02-26 18:12 ` Vladimir Oltean [this message]
2021-02-26 23:19 ` Tobias Waldekranz
2021-02-21 21:33 ` [RFC PATCH net-next 03/12] Documentation: networking: dsa: remove static port count from limitations Vladimir Oltean
2021-02-22 5:13 ` Florian Fainelli
2021-02-21 21:33 ` [RFC PATCH net-next 04/12] Documentation: networking: dsa: remove references to switchdev prepare/commit Vladimir Oltean
2021-02-22 5:13 ` Florian Fainelli
2021-02-24 23:57 ` Andrew Lunn
2021-02-21 21:33 ` [RFC PATCH net-next 05/12] Documentation: networking: dsa: remove TODO about porting more vendor drivers Vladimir Oltean
2021-02-22 5:14 ` Florian Fainelli
2021-02-24 23:59 ` Andrew Lunn
2021-02-21 21:33 ` [RFC PATCH net-next 06/12] Documentation: networking: dsa: document the port_bridge_flags method Vladimir Oltean
2021-02-22 5:15 ` Florian Fainelli
2021-02-25 1:14 ` Andrew Lunn
2021-02-21 21:33 ` [RFC PATCH net-next 07/12] Documentation: networking: dsa: mention integration with devlink Vladimir Oltean
2021-02-22 5:16 ` Florian Fainelli
2021-02-25 1:20 ` Andrew Lunn
2021-02-21 21:33 ` [RFC PATCH net-next 08/12] Documentation: networking: dsa: add paragraph for the LAG offload Vladimir Oltean
2021-02-22 5:18 ` Florian Fainelli
2021-02-25 1:27 ` Andrew Lunn
2021-02-25 20:42 ` Tobias Waldekranz
2021-02-26 18:09 ` Vladimir Oltean
2021-02-21 21:33 ` [RFC PATCH net-next 09/12] Documentation: networking: dsa: add paragraph for the MRP offload Vladimir Oltean
2021-02-22 5:19 ` Florian Fainelli
2021-02-22 19:46 ` Horatiu Vultur
2021-02-22 20:25 ` Vladimir Oltean
2021-02-23 13:30 ` Horatiu Vultur
2021-02-23 13:50 ` Vladimir Oltean
2021-02-23 14:18 ` Horatiu Vultur
2021-02-25 1:32 ` Andrew Lunn
2021-02-21 21:33 ` [RFC PATCH net-next 10/12] Documentation: networking: dsa: add paragraph for the HSR/PRP offload Vladimir Oltean
2021-02-22 5:21 ` Florian Fainelli
2021-02-22 14:48 ` George McCollister
2021-02-25 1:42 ` Andrew Lunn
2021-02-25 13:33 ` George McCollister
2021-02-21 21:33 ` [RFC PATCH net-next 11/12] Documentation: networking: switchdev: clarify device driver behavior Vladimir Oltean
2021-02-25 1:57 ` Andrew Lunn
2021-02-28 16:11 ` Ido Schimmel
2021-02-21 21:33 ` [RFC PATCH net-next 12/12] Documentation: networking: switchdev: fix command for static FDB entries Vladimir Oltean
2021-02-22 5:24 ` Florian Fainelli
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=20210226181250.4km4xf4ntxkts6y7@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=dqfext@gmail.com \
--cc=f.fainelli@gmail.com \
--cc=george.mccollister@gmail.com \
--cc=horatiu.vultur@microchip.com \
--cc=idosch@idosch.org \
--cc=jiri@resnulli.us \
--cc=kurt@linutronix.de \
--cc=netdev@vger.kernel.org \
--cc=tobias@waldekranz.com \
--cc=vivien.didelot@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox