Messages in this thread | | | Date | Tue, 27 Jul 2021 14:57:31 +0300 | From | Vladimir Oltean <> | Subject | Re: [PATCH] dsa: vsc73xx: add support for vlan filtering |
| |
Hi Pawel,
On Thu, Jan 28, 2021 at 02:37:55AM +0200, Vladimir Oltean wrote: > With even more enhancements to the bridge and DSA data path, the source > port information might not even matter for the network stack when the > port is bridged, since the packet will end up in the data path of the > bridge anyway, regardless of which bridged port the packet came in > through (a notable exception to this is link-local traffic like bridge > PDUs - some switches treat link-local packets differently than normal > data ones). On transmission, the imprecise steering to the correct > egress port poses further complications, because of the flooding > implementation in the Linux bridge: a packet that is to be flooded > towards swp0, swp1 and swp2 will be cloned by the bridge once per egress > port, and each skb will be individually delivered to each net_device > driver for xmit. The bridge does not know that the packet transmission > through a DSA driver with no tagging protocol is imprecise, and instead > of delivering the packet just towards the requested egress port, that > the switch will likely flood the packet. So each packet will end up > flooded once by the software bridge, and twice by the hardware bridge. > This can be modeled as a TX-side offload for packet flooding, and could > be used to prevent the bridge from cloning the packets in the first > place, and just deliver them once to a randomly chosen port which is > bridged.
Did you make any progress with getting rid of DSA_TAG_PROTO_NONE for vsc73xx?
Just FYI, the bridge and DSA enhancement that I was talking about above got accepted and you should be able to make use of it. https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=356ae88f8322066a2cd1aee831b7fb768ff2905c https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=beeee08ca1d432891f9e1f6188eea85ffac68527
Assuming you haven't solved your issue with link-local packets, you should at least be able to configure the switch as follows: - in standalone mode and under a VLAN-unaware bridge: enable Shared VLAN Learning, set VLAN_TCI_IGNORE_ENA to always classify packets to the port-based VLAN and not look at the VLAN headers, reserve the 1024-3071 VID range for tag_8021q, and call dsa_tag_8021q_register(). - under a VLAN-aware bridge: same as the above except enable Independent VLAN Learning and disable VLAN_TCI_IGNORE_ENA. Packets from ports under a VLAN-aware bridge will come tagged with the bridge VLAN, so you can draw inspiration from net/dsa/tag_sja1105.c to see how to perform reception for those (dsa_find_designated_bridge_port_by_vid). This should give you the ability to expose the switch as an STP-incapable bridge accelerator with port isolation and VLAN support, which frankly seems about all that the hardware can offer.
| |