On Sun, Feb 14, 2021 at 05:53:22PM +0200, Vladimir Oltean wrote: > From: Vladimir Oltean <vladimir.olt...@nxp.com> > > As was discussed here: > https://patchwork.kernel.org/project/netdevbpf/patch/20201202091356.24075-3-tob...@waldekranz.com/ > > it is desirable to not reject a LAG interface (bonding, team) even if > the switch isn't able to offload bridging towards that link aggregation > group. At least the DSA setups I have are not that unbalanced between > the horsepower of the CPU and the horsepower of the switch such that > software forwarding to be completely impractical. > > This series makes all switch drivers theoretically able to do the right > thing when they are configured in a way similar to this (credits to > Tobias Waldekranz for the drawing): > > br0 > / \ > team0 \ > / \ \ > swp0 swp1 swp2 > > although in practice there is one more prerequisite: for software > fallback mode, they need to disable address learning. It is preferable > that they do this by implementing the .port_pre_bridge_join and > .port_bridge_join methods.
Sadly there is some false marketing on my part here and this series is probably not enough for the above configuration to work in software. I have to confess that I tested with software bridging, and with software LAG, but not with both at the same time. I sent this series way too quickly and I should probably spend more time on it. Sorry to everyone copied for the noise.
