+149
−291
+10
−0
+0
−15
Loading
Merge branch 'sja1105-bridge-port-traffic-termination'
Vladimir Oltean says: ==================== Traffic termination for sja1105 ports under VLAN-aware bridge 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 b8b79c41 ("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. ==================== Signed-off-by:David S. Miller <davem@davemloft.net>