From: Florian Fainelli <f.fainelli@gmail.com>
To: Vladimir Oltean <olteanv@gmail.com>,
andrew@lunn.ch, vivien.didelot@gmail.com, davem@davemloft.net
Cc: jiri@resnulli.us, idosch@idosch.org, kuba@kernel.org,
netdev@vger.kernel.org, nikolay@cumulusnetworks.com,
roopa@cumulusnetworks.com, mingkai.hu@nxp.com
Subject: Re: [PATCH v3 net-next 2/4] net: dsa: permit cross-chip bridging between all trees in the system
Date: Thu, 7 May 2020 20:16:49 -0700 [thread overview]
Message-ID: <d4e0a8cf-a059-ff41-8e3e-0bd1fd7b0523@gmail.com> (raw)
In-Reply-To: <20200503221228.10928-3-olteanv@gmail.com>
On 5/3/2020 3:12 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> One way of utilizing DSA is by cascading switches which do not all have
> compatible taggers. Consider the following real-life topology:
>
> +---------------------------------------------------------------+
> | LS1028A |
> | +------------------------------+ |
> | | DSA master for Felix | |
> | |(internal ENETC port 2: eno2))| |
> | +------------+------------------------------+-------------+ |
> | | Felix embedded L2 switch | |
> | | | |
> | | +--------------+ +--------------+ +--------------+ | |
> | | |DSA master for| |DSA master for| |DSA master for| | |
> | | | SJA1105 1 | | SJA1105 2 | | SJA1105 3 | | |
> | | |(Felix port 1)| |(Felix port 2)| |(Felix port 3)| | |
> +--+-+--------------+---+--------------+---+--------------+--+--+
>
> +-----------------------+ +-----------------------+ +-----------------------+
> | SJA1105 switch 1 | | SJA1105 switch 2 | | SJA1105 switch 3 |
> +-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
> |sw1p0|sw1p1|sw1p2|sw1p3| |sw2p0|sw2p1|sw2p2|sw2p3| |sw3p0|sw3p1|sw3p2|sw3p3|
> +-----+-----+-----+-----+ +-----+-----+-----+-----+ +-----+-----+-----+-----+
>
> The above can be described in the device tree as follows (obviously not
> complete):
>
> mscc_felix {
> dsa,member = <0 0>;
> ports {
> port@4 {
> ethernet = <&enetc_port2>;
> };
> };
> };
>
> sja1105_switch1 {
> dsa,member = <1 1>;
> ports {
> port@4 {
> ethernet = <&mscc_felix_port1>;
> };
> };
> };
>
> sja1105_switch2 {
> dsa,member = <2 2>;
> ports {
> port@4 {
> ethernet = <&mscc_felix_port2>;
> };
> };
> };
>
> sja1105_switch3 {
> dsa,member = <3 3>;
> ports {
> port@4 {
> ethernet = <&mscc_felix_port3>;
> };
> };
> };
>
> Basically we instantiate one DSA switch tree for every hardware switch
> in the system, but we still give them globally unique switch IDs (will
> come back to that later). Having 3 disjoint switch trees makes the
> tagger drivers "just work", because net devices are registered for the
> 3 Felix DSA master ports, and they are also DSA slave ports to the ENETC
> port. So packets received on the ENETC port are stripped of their
> stacked DSA tags one by one.
>
> Currently, hardware bridging between ports on the same sja1105 chip is
> possible, but switching between sja1105 ports on different chips is
> handled by the software bridge. This is fine, but we can do better.
>
> In fact, the dsa_8021q tag used by sja1105 is compatible with cascading.
> In other words, a sja1105 switch can correctly parse and route a packet
> containing a dsa_8021q tag. So if we could enable hardware bridging on
> the Felix DSA master ports, cross-chip bridging could be completely
> offloaded.
>
> Such as system would be used as follows:
>
> ip link add dev br0 type bridge && ip link set dev br0 up
> for port in sw0p0 sw0p1 sw0p2 sw0p3 \
> sw1p0 sw1p1 sw1p2 sw1p3 \
> sw2p0 sw2p1 sw2p2 sw2p3; do
> ip link set dev $port master br0
> done
>
> The above makes switching between ports on the same row be performed in
> hardware, and between ports on different rows in software. Now assume
> the Felix switch ports are called swp0, swp1, swp2. By running the
> following extra commands:
>
> ip link add dev br1 type bridge && ip link set dev br1 up
> for port in swp0 swp1 swp2; do
> ip link set dev $port master br1
> done
>
> the CPU no longer sees packets which traverse sja1105 switch boundaries
> and can be forwarded directly by Felix. The br1 bridge would not be used
> for any sort of traffic termination.
Is there anything that prevents br1 from terminating traffic though
(just curious)?
>
> For this to work, we need to give drivers an opportunity to listen for
> bridging events on DSA trees other than their own, and pass that other
> tree index as argument. I have made the assumption, for the moment, that
> the other existing DSA notifiers don't need to be broadcast to other
> trees. That assumption might turn out to be incorrect. But in the
> meantime, introduce a dsa_broadcast function, similar in purpose to
> dsa_port_notify, which is used only by the bridging notifiers.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
next prev parent reply other threads:[~2020-05-08 3:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-03 22:12 [PATCH v3 net-next 0/4] Cross-chip bridging for disjoint DSA trees Vladimir Oltean
2020-05-03 22:12 ` [PATCH v3 net-next 1/4] net: bridge: allow enslaving some DSA master network devices Vladimir Oltean
2020-05-08 2:38 ` Florian Fainelli
2020-05-03 22:12 ` [PATCH v3 net-next 2/4] net: dsa: permit cross-chip bridging between all trees in the system Vladimir Oltean
2020-05-08 3:16 ` Florian Fainelli [this message]
2020-05-08 12:54 ` Vladimir Oltean
2020-05-03 22:12 ` [PATCH v3 net-next 3/4] net: dsa: introduce a dsa_switch_find function Vladimir Oltean
2020-05-08 2:39 ` Florian Fainelli
2020-05-03 22:12 ` [PATCH v3 net-next 4/4] net: dsa: sja1105: implement cross-chip bridging operations Vladimir Oltean
2020-05-08 3:32 ` Florian Fainelli
2020-05-07 16:07 ` [PATCH v3 net-next 0/4] Cross-chip bridging for disjoint DSA trees Vladimir Oltean
2020-05-07 22:15 ` David Miller
2020-05-07 22:36 ` 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=d4e0a8cf-a059-ff41-8e3e-0bd1fd7b0523@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=idosch@idosch.org \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=mingkai.hu@nxp.com \
--cc=netdev@vger.kernel.org \
--cc=nikolay@cumulusnetworks.com \
--cc=olteanv@gmail.com \
--cc=roopa@cumulusnetworks.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;
as well as URLs for NNTP newsgroup(s).