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:   Thu, 3 Dec 2020 20:18:54 -0800
From:   Florian Fainelli <>
To:     Andrew Lunn <>, Vladimir Oltean <>
Cc:     Tobias Waldekranz <>,,,,,,,
Subject: Re: [PATCH v3 net-next 2/4] net: dsa: Link aggregation support

On 12/3/2020 5:33 PM, Andrew Lunn wrote:
>> Of course, neither is fully correct. There is always more to improve on
>> the communication side of things.
> I wonder if switchdev needs to gain an enumeration API? A way to ask
> the underlying driver, what can you offload? The user can then get an
> idea what is likely to be offloaded, and what not. If that API is fine
> grain enough, it can list the different LAG algorithms supported.

For stack offloads we can probably easily agree on what constitutes a
vendor neutral offload and a name for that enumeration. For other
features this is going to become an unmaintainable list of features and
then we are no better than we started 6 years ago with submitting
OpenWrt's swconfig and each switch driver advertising its features and
configuration API via netlink.

NETIF_F_SWITCHDEV_OFFLOAD would not be fine grained enough, this needs
to be a per action selection, just like when offloading the bridge, or
tc, you need to be able to hint the driver whether the offload is being
requested by the user.

For now, I would just go with implicitly falling back to doing the LAG
in software if the requested mode is not supported and leveraging extack
to indicate that was the case.

Powered by blists - more mailing lists