[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201028233507.68188398@nic.cz>
Date: Wed, 28 Oct 2020 23:35:07 +0100
From: Marek Behun <marek.behun@....cz>
To: Tobias Waldekranz <tobias@...dekranz.com>
Cc: Andrew Lunn <andrew@...n.ch>, 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, 27 Oct 2020 19:25:16 +0100
Tobias Waldekranz <tobias@...dekranz.com> wrote:
> .-----. 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.
The hashing is horrible :( On Turris Omnia we have 5 user ports and 2
CPU ports, and I suspect that for most of our users there is at most
one peer MAC address on the other side of an user port. So if such a
user has 5 devices connected to each switch port, there are 5 pairs of
(DA,SA), so 2^5 = 32 different assignments of (DA,SA) pairs to CPU
ports.
With probability 2/32 = 6.25% traffic from all 5 user ports would go via
one port,
with probability 10/32 = 31.25% traffic from 4 user ports would go via
one port.
That is not good balancing :)
Marek
Powered by blists - more mailing lists