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  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:   Wed, 9 Dec 2020 12:53:26 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Tobias Waldekranz <tobias@...dekranz.com>
Cc:     davem@...emloft.net, kuba@...nel.org, andrew@...n.ch,
        vivien.didelot@...il.com, f.fainelli@...il.com,
        j.vosburgh@...il.com, vfalico@...il.com, andy@...yhouse.net,
        netdev@...r.kernel.org
Subject: Re: [PATCH v3 net-next 2/4] net: dsa: Link aggregation support

On Wed, Dec 09, 2020 at 09:37:39AM +0100, Tobias Waldekranz wrote:
> I will remove `struct dsa_lag` in v4.

Ok, thanks.
It would be nice if you could also make .port_lag_leave return an int code.
And I think that .port_lag_change passes more arguments than needed to
the driver.

> > I don't think the DSA switch tree is private to anyone.
>
> Well I need somewhere to store the association from LAG netdev to LAG
> ID. These IDs are shared by all chips in the tree. It could be
> replicated on each ds of course, but that does not feel quite right.

The LAG ID does not have significance beyond the mv88e6xxx driver, does
it? And even there, it's just a number. You could recalculate all IDs
dynamically upon every join/leave, and they would be consistent by
virtue of the fact that you use a formula which ensures consistency
without storing the LAG ID anywhere. Like, say, the LAG ID is to be
determined by the first struct dsa_port in the DSA switch tree that has
dp->bond == lag_dev. The ID itself can be equal to (dp->ds->index *
MAX_NUM_PORTS + dp->index). All switches will agree on what is the first
dp in dst, since they iterate in the same way, and any LAG join/leave
will notify all of them. It has to be like this anyway.

Powered by blists - more mailing lists