netdev - Re: [PATCH v3 net-next 2/4] net: dsa: permit cross-chip bridging between all trees in the system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 7 May 2020 20:16:49 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>, andrew@...n.ch,
        vivien.didelot@...il.com, davem@...emloft.net
Cc:     jiri@...nulli.us, idosch@...sch.org, kuba@...nel.org,
        netdev@...r.kernel.org, nikolay@...ulusnetworks.com,
        roopa@...ulusnetworks.com, mingkai.hu@....com
Subject: Re: [PATCH v3 net-next 2/4] net: dsa: permit cross-chip bridging
 between all trees in the system



On 5/3/2020 3:12 PM, Vladimir Oltean wrote:
> From: Vladimir Oltean <vladimir.oltean@....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@....com>
> ---
Reviewed-by: Florian Fainelli <f.fainelli@...il.com>
-- 
Florian