netdev - Re: [RFC PATCH 0/4] net: dsa: link aggregation support

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:   Tue, 27 Oct 2020 19:25:16 +0100
From:   Tobias Waldekranz <tobias@...dekranz.com>
To:     Andrew Lunn <andrew@...n.ch>, Marek Behun <marek.behun@....cz>
Cc:     vivien.didelot@...il.com, f.fainelli@...il.com, olteanv@...il.com,
        netdev@...r.kernel.org
Subject: Re: [RFC PATCH 0/4] net: dsa: link aggregation support

On Tue, Oct 27, 2020 at 16:23, Andrew Lunn <andrew@...n.ch> wrote:
> Hi Marek
>
> trunking is something i've looked at once, but never had time to work
> on. There are three different use cases i thought of:
>
> 1) trunk user ports, with team/bonding controlling it
> 2) trunk DSA ports, i.e. the ports between switches in a D in DSA setup
> 3) trunk CPU ports.
>
> What Tobias is implementing here is 1). This seems like a good first
> step.
>
> I'm not sure 3) is even possible. Or it might depend on the switch
> generation. The 6352 for example, the CPU Dest field is a port
> number. It does not appear to allow for a trunk. 6390 moved this
> register, but as far as i know, it did not add trunk support.  It
> might be possible to have multiple SoC interfaces sending frames to
> the Switch using DSA tags, but i don't see a way to have the switch
> send frames to the SoC using multiple ports.

I think that (2) and (3) are essentially the same problem, i.e. creating
LAGs out of DSA links, be they switch-to-switch or switch-to-cpu
connections. I think you are correct that the CPU port can not be a
LAG/trunk, but I believe that limitation only applies to TO_CPU packets.
If the CPU ports configured as a LAG, all FORWARDs, i.e. the bulk
traffic, would benefit from the load-balancing. Something like this:

.-----. TO_CPU, FORWARD .-----. TO_CPU, FORWARD .-----.
|     +-----------------+     +-----------------+     |
| CPU |                 | sw0 |                 | sw1 |
|     +-----------------+     +-----------------+     |
'-----'    FORWARD      '-+-+-'    FORWARD      '-+-+-'
                          | |                     | |
                       swp1 swp2               swp3 swp4

So the links selected as the CPU ports will see a marginally higher load
due to all TO_CPU being sent over it. But the hashing is not that great
on this hardware anyway (DA/SA only) so some imbalance is unavoidable.

In order for this to work on transmit, we need to add forward offloading
to the bridge so that we can, for example, send one FORWARD from the CPU
to send an ARP broadcast to swp1..4 instead of four FROM_CPUs.

	Tobias