| Message ID | 20210214155326.1783266-1-olteanv@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Software fallback for bridging in DSA | expand |
On Sun, Feb 14, 2021 at 05:53:22PM +0200, Vladimir Oltean wrote: > From: Vladimir Oltean <vladimir.oltean@nxp.com> > > As was discussed here: > https://patchwork.kernel.org/project/netdevbpf/patch/20201202091356.24075-3-tobias@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.
From: Vladimir Oltean <vladimir.oltean@nxp.com> As was discussed here: https://patchwork.kernel.org/project/netdevbpf/patch/20201202091356.24075-3-tobias@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. Vladimir Oltean (4): net: dsa: don't offload switchdev objects on ports that don't offload the bridge net: dsa: reject switchdev objects centrally from dsa_slave_port_obj_{add,del} net: dsa: return -EOPNOTSUPP if .port_lag_join is not implemented net: dsa: don't set skb->offload_fwd_mark when not offloading the bridge net/dsa/dsa_priv.h | 16 ++++++++++++++++ net/dsa/slave.c | 21 +++++++++++---------- net/dsa/switch.c | 13 ++++++++++--- net/dsa/tag_brcm.c | 2 +- net/dsa/tag_dsa.c | 9 +++++---- net/dsa/tag_hellcreek.c | 2 +- net/dsa/tag_ksz.c | 2 +- net/dsa/tag_lan9303.c | 4 +++- net/dsa/tag_mtk.c | 2 +- net/dsa/tag_ocelot.c | 2 +- net/dsa/tag_ocelot_8021q.c | 2 +- net/dsa/tag_rtl4_a.c | 2 +- net/dsa/tag_sja1105.c | 4 ++-- net/dsa/tag_xrs700x.c | 3 +-- 14 files changed, 55 insertions(+), 29 deletions(-)