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.