Thread (59 messages) 59 messages, 7 authors, 2020-12-16

Re: [PATCH v3 net-next 2/4] net: dsa: Link aggregation support

From: Tobias Waldekranz <tobias@waldekranz.com>
Date: 2020-12-07 21:57:42

On Thu, Dec 03, 2020 at 20:18, Florian Fainelli [off-list ref] wrote:
On 12/3/2020 5:33 PM, Andrew Lunn wrote:
quoted
quoted
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.
That makes sense. So you are talking about adding something akin to tc's
skip_hw/skip_sw to `ip link`?
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.
Ahh, you can use extack for successful operations? I did not know that,
I think that strikes a good balance.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help