netdev - Re: [PATCH net-next 2/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] [day] [month] [year] [list]

Message-Id: <C7F5NW46RGKW.HWQYN850NOTL@wkz-x280>
Date:   Sat, 28 Nov 2020 20:48:52 +0100
From:   "Tobias Waldekranz" <tobias@...dekranz.com>
To:     "Andrew Lunn" <andrew@...n.ch>,
        "Florian Fainelli" <f.fainelli@...il.com>
Cc:     "Tobias Waldekranz" <tobias@...dekranz.com>, <davem@...emloft.net>,
        <kuba@...nel.org>, <vivien.didelot@...il.com>, <olteanv@...il.com>,
        <j.vosburgh@...il.com>, <vfalico@...il.com>, <andy@...yhouse.net>,
        <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 2/4] net: dsa: Link aggregation support

On Sat Nov 28, 2020 at 6:38 PM CET, Andrew Lunn wrote:
> > > OK I think I finally see what you are saying. Sorry it took me this
> > > long. I do not mean to be difficult, I just want to understand.
>
> Not a problem. This is a bit different to normal, the complexity of
> the stack means you need to handle this different to most drivers. If
> you have done any deeply embedded stuff, RTOS, allocating everything
> up front is normal, it eliminates a whole class of problems.

Yeah I am well aware, Linux is pretty far from that kind of embedded
though :)

The problem here, IMHO, is not really the allocation. Rather we want
to shift as much work as possible from CHANGEUPPER to PRECHANGEUPPER
to signal errors early, this was the part that was not clicking for
me.

And you can not allocate anything in PRECHANGE, because there may
never be a corresponding CHANGEUPPER if another subscriber on the
chain throws an error. _That_ is what forces you to use the static
array.

> This is all reasonable. I just wonder what that number is for the
> mv88e6xx case, especially for D in DSA. I guess LAGs are global in
> scope across a set of switches. So it does not matter if there is one
> switch or lots of switches, the lags_max stays the same.

For everything up to Agate, the max is 16. Peridot (and I guess Topaz)
can potentially do 32, but mv88e6xxx never sets the "5-bit port" mode
AFAIK, so in practice the max is 16 across the board.

Yes the LAG IDs are global, they must be configured on all switches,
even those that have no local member ports. So the pool will hold 16
entries on a mv88e6xxx tree.