| Message ID | 20210113084255.22675-1-tobias@waldekranz.com |
|---|---|
| Headers | show |
| Series | net: dsa: Link aggregation support | expand |
On Wed, Jan 13, 2021 at 09:42:52AM +0100, Tobias Waldekranz wrote: > In a situation where a standalone port is indirectly attached to a > bridge (e.g. via a LAG) which is not offloaded, do not offload any > port attributes either. The port should behave as a standard NIC. > > Previously, on mv88e6xxx, this meant that in the following setup: > > br0 > / > team0 > / \ > swp0 swp1 > > If vlan filtering was enabled on br0, swp0's and swp1's QMode was set > to "secure". This caused all untagged packets to be dropped, as their > default VID (0) was not loaded into the VTU. > > Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> > --- Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
On Wed, Jan 13, 2021 at 09:42:54AM +0100, Tobias Waldekranz wrote: > Support offloading of LAGs to hardware. LAGs may be attached to a > bridge in which case VLANs, multicast groups, etc. are also offloaded > as usual. > > Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> > --- Reviewed-by: Vladimir Oltean <olteanv@gmail.com> > +static bool mv88e6xxx_lag_can_offload(struct dsa_switch *ds, > + struct net_device *lag, > + struct netdev_lag_upper_info *info) > +{ > + struct dsa_port *dp; > + int id, members = 0; > + > + id = dsa_lag_id(ds->dst, lag); > + if (id < 0 || id >= ds->num_lag_ids) This "id >= ds->num_lag_ids" condition is there just in the off chance that the mv88e6xxx could be bridged in the same DSA tree with another device that reports a higher ds->num_lag_ids such that dst->lags_len picks up that larger maximum, but otherwise the two switches have the same understanding of the LAG ID, and are compatible with one another? That sounds... plausible?
On Thu, Jan 14, 2021 at 02:50, Vladimir Oltean <olteanv@gmail.com> wrote: > On Wed, Jan 13, 2021 at 09:42:54AM +0100, Tobias Waldekranz wrote: >> Support offloading of LAGs to hardware. LAGs may be attached to a >> bridge in which case VLANs, multicast groups, etc. are also offloaded >> as usual. >> >> Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com> >> --- > > Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Thanks! >> +static bool mv88e6xxx_lag_can_offload(struct dsa_switch *ds, >> + struct net_device *lag, >> + struct netdev_lag_upper_info *info) >> +{ >> + struct dsa_port *dp; >> + int id, members = 0; >> + >> + id = dsa_lag_id(ds->dst, lag); >> + if (id < 0 || id >= ds->num_lag_ids) > > This "id >= ds->num_lag_ids" condition is there just in the off chance > that the mv88e6xxx could be bridged in the same DSA tree with another > device that reports a higher ds->num_lag_ids such that dst->lags_len > picks up that larger maximum, but otherwise the two switches have the > same understanding of the LAG ID, and are compatible with one another? Exactly so. > That sounds... plausible? While improbable, it is possible. Older 6xxx chips can only handle 16 LAGs, newer chips can handle up to 32. This is not supported by the driver at the moment - still it felt easier to add the check now, rather than having the future developer chase down the resulting bug in five years when they add that support.
Hello: This series was applied to netdev/net-next.git (refs/heads/master): On Wed, 13 Jan 2021 09:42:50 +0100 you wrote: > Start of by adding an extra notification when adding a port to a bond, > this allows static LAGs to be offloaded using the bonding driver. > > Then add the generic support required to offload link aggregates to > drivers built on top of the DSA subsystem. > > Finally, implement offloading for the mv88e6xxx driver, i.e. Marvell's > LinkStreet family. > > [...] Here is the summary with links: - [v5,net-next,1/5] net: bonding: Notify ports about their initial state https://git.kernel.org/netdev/net-next/c/32d4c5647aad - [v5,net-next,2/5] net: dsa: Don't offload port attributes on standalone ports https://git.kernel.org/netdev/net-next/c/5696c8aedfcc - [v5,net-next,3/5] net: dsa: Link aggregation support https://git.kernel.org/netdev/net-next/c/058102a6e9eb - [v5,net-next,4/5] net: dsa: mv88e6xxx: Link aggregation support https://git.kernel.org/netdev/net-next/c/57e661aae6a8 - [v5,net-next,5/5] net: dsa: tag_dsa: Support reception of packets from LAG devices https://git.kernel.org/netdev/net-next/c/5b60dadb71db You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
Start of by adding an extra notification when adding a port to a bond, this allows static LAGs to be offloaded using the bonding driver. Then add the generic support required to offload link aggregates to drivers built on top of the DSA subsystem. Finally, implement offloading for the mv88e6xxx driver, i.e. Marvell's LinkStreet family. Supported LAG implementations: - Bonding - Team Supported modes: - Isolated. The LAG may be used as a regular interface outside of any bridge. - Bridged. The LAG may be added to a bridge, in which case switching is offloaded between the LAG and any other switch ports. I.e. the LAG behaves just like a port from this perspective. In bridged mode, the following is supported: - STP filtering. - VLAN filtering. - Multicast filtering. The bridge correctly snoops IGMP and configures the proper groups if snooping is enabled. Static groups can also be configured. MLD seems to work, but has not been extensively tested. - Unicast filtering. Automatic learning works. Static entries are _not_ supported. This will be added in a later series as it requires some more general refactoring in mv88e6xxx before I can test it. v4 -> v5: - Cleanup PVT configuration for LAGed ports in mv88e6xxx (Vladimir) - Document dsa_lag_{map,unmap} (Vladimir) v3 -> v4: - Remove `struct dsa_lag`, leaving only a linear mapping to/from ID/netdev that drivers can opt-in to. - Always fallback to a software LAG if offloading is not possible. - mv88e6xxx: Do not offload unless the LAG mode matches what the hardware can do (hash based balancing). v2 -> v3: - Skip unnecessary RCU protection of the LAG device pointer, as suggested by Vladimir. - Refcount LAGs with a plain refcount_t instead of `struct kref`, as suggested by Vladimir. v1 -> v2: - Allocate LAGs from a static pool to avoid late errors under memory pressure, as suggested by Andrew. RFC -> v1: - Properly propagate MDB operations. - Support for bonding in addition to team. - Fixed a locking bug in mv88e6xxx. - Make sure ports are disabled-by-default in mv88e6xxx. - Support for both DSA and EDSA tagging. Tobias Waldekranz (5): net: bonding: Notify ports about their initial state net: dsa: Don't offload port attributes on standalone ports net: dsa: Link aggregation support net: dsa: mv88e6xxx: Link aggregation support net: dsa: tag_dsa: Support reception of packets from LAG devices drivers/net/bonding/bond_main.c | 2 + drivers/net/dsa/mv88e6xxx/chip.c | 296 +++++++++++++++++++++++++++- drivers/net/dsa/mv88e6xxx/global2.c | 8 +- drivers/net/dsa/mv88e6xxx/global2.h | 5 + drivers/net/dsa/mv88e6xxx/port.c | 21 ++ drivers/net/dsa/mv88e6xxx/port.h | 5 + include/net/dsa.h | 60 ++++++ net/dsa/dsa.c | 12 +- net/dsa/dsa2.c | 93 +++++++++ net/dsa/dsa_priv.h | 36 ++++ net/dsa/port.c | 79 ++++++++ net/dsa/slave.c | 71 ++++++- net/dsa/switch.c | 50 +++++ net/dsa/tag_dsa.c | 17 +- 14 files changed, 742 insertions(+), 13 deletions(-)