| Message ID | 20210726165536.1338471-1-vladimir.oltean@nxp.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Traffic termination for sja1105 ports under VLAN-aware bridge | expand |
Hello: This series was applied to netdev/net-next.git (refs/heads/master): On Mon, 26 Jul 2021 19:55:27 +0300 you wrote: > This set of patches updates the sja1105 DSA driver to be able to send > and receive network stack packets on behalf of a VLAN-aware upper bridge > interface. > > The reasons why this has traditionally been a problem are explained in > the "Traffic support" section of Documentation/networking/dsa/sja1105.rst. > (the entire documentation will be revised in a separate patch series). > > [...] Here is the summary with links: - [net-next,1/9] net: bridge: update BROPT_VLAN_ENABLED before notifying switchdev in br_vlan_filter_toggle https://git.kernel.org/netdev/net-next/c/f7cdb3ecc9b7 - [net-next,2/9] net: bridge: add a helper for retrieving port VLANs from the data path https://git.kernel.org/netdev/net-next/c/ee80dd2e89ec - [net-next,3/9] net: dsa: sja1105: remove redundant re-assignment of pointer table https://git.kernel.org/netdev/net-next/c/d63f8877c48c - [net-next,4/9] net: dsa: sja1105: delete vlan delta save/restore logic https://git.kernel.org/netdev/net-next/c/6dfd23d35e75 - [net-next,5/9] net: dsa: sja1105: deny 8021q uppers on ports https://git.kernel.org/netdev/net-next/c/4fbc08bd3665 - [net-next,6/9] net: dsa: sja1105: deny more than one VLAN-aware bridge https://git.kernel.org/netdev/net-next/c/19fa937a391e - [net-next,7/9] net: dsa: sja1105: add support for imprecise RX https://git.kernel.org/netdev/net-next/c/884be12f8566 - [net-next,8/9] net: dsa: sja1105: add bridge TX data plane offload based on tag_8021q https://git.kernel.org/netdev/net-next/c/b6ad86e6ad6c - [net-next,9/9] Revert "net: dsa: Allow drivers to filter packets they can decode source port from" https://git.kernel.org/netdev/net-next/c/edac6f6332d9 You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html
This set of patches updates the sja1105 DSA driver to be able to send and receive network stack packets on behalf of a VLAN-aware upper bridge interface. The reasons why this has traditionally been a problem are explained in the "Traffic support" section of Documentation/networking/dsa/sja1105.rst. (the entire documentation will be revised in a separate patch series). The limitations that have prevented us from doing this so far have now been partially lifted by the bridge's ability to send a packet with skb->offload_fwd_mark = true, which means that the accelerator is allowed to look up its hardware FDB when sending a packet and deliver it to those destination ports. Basically skb->dev is now just a conduit to the switchdev driver's ndo_start_xmit(), and does not guarantee that the packet will really be transmitted on that port (but it will be transmitted where it should, nonetheless). Apart from the ability to perform IP termination on VLAN-aware bridges on top of sja1105 interfaces, we also gain the following features: - VLAN-aware software bridging between sja1105 ports and "foreign" (non-DSA) interfaces - software bridging between sja1105 bridge ports, and software LAG uppers of sja1105 ports (as long as the bridge is VLAN-aware) The only things that don't work are: 1. to create an AF_PACKET socket on top of a sja1105 port that is under a VLAN-aware bridge. This is because the "imprecise RX" procedure selects an RX port for data plane* packets based on the assumption that the packet will land in the bridge's data path. If ebtables rules are added to remove some packets from the bridge's data path, that assumption will be broken. Nonetheless, this is not a limitation that negatively impacts the known use cases with this switch. If there was a way to impose user space restrictions against creating AF_PACKET sockets on this particular configuration, I could be interested in adding those restrictions, but I think there are other known broken configs already which are not checked by the kernel today (like for example that the bridge's rx_handler steals packets anyway from AF_PACKET sockets with exact-match ptype handlers, as opposed to ptype_all which are processed earlier; this is precisely the reason why ebtables rules are generally needed to avoid that). 2. to send traffic on behalf of an 8021q upper of a standalone interface, while other sja1105 ports are part of a VLAN-aware bridge. This is because sja1105 sets ds->vlan_filtering_is_global = true, so we cannot make the standalone port ignore the VLAN header from the packet on RX, so we cannot make tag_8021q enforce its own pvid for the packets belonging to that port's 8021q upper. So we cannot determine in the first place that packets come from that port, unless we iterate through all 8021q uppers of all ports, and enforce uniqueness of VLAN IDs. I am not sure if this is what I want / if it is worth it, so currently all 8021q uppers are denied, regardless of whether the switch has ports under a VLAN-aware bridge or not (otherwise it becomes complicated even to track the state). Nonetheless, the VID uniqueness of all 8021q uppers does raise another question: what to do with VID 0, which has no 8021q upper, but the 8021q module adds it to our RX filter with vlan_vid_add(). I am honestly not sure what to do. The best I can do is enable a hardware bit in sja1105 which reclassifies VID 0 frames to the PVID, and they will be sent on the CPU port using either the tag_8021q pvid of standalone ports, or the bridge pvid of VLAN-aware ports. So at the very least, those packets are still 'kinda' processed as if they were untagged, but the VID 0 is lost, though. In my defence, Marvell appears to do the same thing with reclassifying VID 0 frames, see commit b8b79c414eca ("net: dsa: mv88e6xxx: Fix adding vlan 0"). *Control packets (currently hardcoded in sja1105 as link-local packets for MAC DA ranges 01-80-c2-xx-xx-xx and 01-1b-19-xx-xx-xx) are received based on packet traps and their precise source port is always known. I have taken one patch from Colin because my work conflicts with his, and integrating it all through the same series avoids that. Cc: Roopa Prabhu <roopa@nvidia.com> Cc: Nikolay Aleksandrov <nikolay@nvidia.com> Cc: Ido Schimmel <idosch@nvidia.com> Cc: Jiri Pirko <jiri@nvidia.com> Cc: Colin Ian King <colin.king@canonical.com> Colin Ian King (1): net: dsa: sja1105: remove redundant re-assignment of pointer table Vladimir Oltean (8): net: bridge: update BROPT_VLAN_ENABLED before notifying switchdev in br_vlan_filter_toggle net: bridge: add a helper for retrieving port VLANs from the data path net: dsa: sja1105: delete vlan delta save/restore logic net: dsa: sja1105: deny 8021q uppers on ports net: dsa: sja1105: deny more than one VLAN-aware bridge net: dsa: sja1105: add support for imprecise RX net: dsa: sja1105: add bridge TX data plane offload based on tag_8021q Revert "net: dsa: Allow drivers to filter packets they can decode source port from" drivers/net/dsa/sja1105/sja1105.h | 12 +- drivers/net/dsa/sja1105/sja1105_main.c | 440 +++++++++---------------- include/linux/dsa/8021q.h | 10 + include/linux/if_bridge.h | 8 + include/net/dsa.h | 15 - net/bridge/br_vlan.c | 34 +- net/dsa/dsa_priv.h | 43 +++ net/dsa/port.c | 1 - net/dsa/tag_8021q.c | 48 ++- net/dsa/tag_sja1105.c | 118 ++++--- net/ethernet/eth.c | 6 +- 11 files changed, 363 insertions(+), 372 deletions(-)