On Thu, Dec 03, 2020 at 22:09, Andrew Lunn [off-list ref] wrote:

quoted

One could argue that if Linus had received an error instead, adapted his
teamd config and tried again, he would be a happier user and we might
not have to compete with his OS.

I am not sure which way is the correct one, but I do not think that it
necessarily _always_ correct to silently fallback to a non-offloaded
mode.

This is an argument Mellanox makes, where falling back to software
would be a bad idea given the huge bandwidth of their hardware
accelerator, and the slow bandwidth of their CPU.

Yeah when you have 100G interfaces the choice becomes easier :)

If the switch has no hardware support for LAG at all, then falling
back to software is reasonable. It is less clear when there is some
support in the switch. If we do reject it, we should try to make use
of extack to give the user a useful error messages: Not supported, try
configuration XYZ. But i guess that needs some plumbing, getting
extack available in the place we make the decision.

I do not think we need to add anything. Looking at mlxsw, the extack is
available in the `struct netdev_notifier_changeupper_info`.

I am leaning towards the behavior you just described:

- If there is no offloading available, accept anything and let the
  software take care of it. The user wants a LAG and that is the best we
  can do.

- If offloading is available, reject anything that can not be
  offloaded. My guess is that _any_ hardware offloaded setup will almost
  always yield a better solution for the user than a software fallback.