lkml.org 
[lkml]   [2021]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.

\
 
 \ /
  Last update: 2021-07-27 13:58    [W:0.077 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site