Hi Pawel, Linus, On Fri, 19 Jul 2019 at 12:22, Paweł Dembicki <paweldembi...@gmail.com> wrote: > > > On Fri, Jul 19, 2019 at 09:51 Linus Walleij <linus.wall...@linaro.org> > > wrote: > > > > > I think, that the best approach is vlan filtering. I started some work: > > > https://github.com/CHKDSK88/linux/commit/38b62482d9f828b5720db11145fa474e368b248c > > > > Hey! I wanted to do that but never had time, > > so very happy that you're fixing it up! :) > > > > It would be great if You found some time to test it. :) > > > > At this moment it works (I used ip-full and ip-bridge packets). But I > > > have no idea how to integrate dsa vlan filtering with OpenWRT > > > configuration. > > > This is first dsa switch with DSA_TAG_PROTO_NONE in OpenWRT. > > > > I think in the upstream kernel look at > > commit f9bbe4477c30ece44296437ee26142b42ef8070b > > "net: dsa: Optional VLAN-based port separation for switches without tagging" > > by Vladimir Oltean. > > > > I intuitively think this is what we want to do in the end is use > > DSA_TAG_PROTO_8021Q but admittedly I don't think I > > understand VLANs well enough for enabling this. > > > > This is the question for OpenWRT core developers. What is the best > approach for DSA_TAG_PROTO_NONE switches? > > DSA_TAG_PROTO_8021Q or just vlan filtering and configuration without > tagging support? Both solutions can give You port separation. > > Personally I prefer simple vlan separation. This method was used in > OpenWRT for many non-dsa switches. But it need to create API for dsa > devices. >
I have never used OpenWRT on a board having an L2 switch so I don't know how traffic over the switch ports is managed there. In theory it is possible to transplant the dsa_port_setup_8021q_tagging function from net/dsa/tag_8021q.c into a shell script that operates with 'bridge vlan' operations. However you will quickly find that you will need to do 'bridge vlan add vid ${rx_vid} dev ${cpu_port}' aka "tagged egress" <- but surprise, there is no CPU port net device exposed to userspace. I see you overcame this by hardcoding the CPU port as a VLAN trunk for all VLANs added on the user ports. This is going to work as a hack, but you will need to add 2 VLAN sub-interfaces to the master port per switch front-panel port - one for TX and another for RX. Otherwise you will have the switch work as standalone net devices, but you'll break its core functionality - switching. And you'll likely need to do exotic things with applications that need bidirectional communication over switch ports, because ingress and egress will happen over different interfaces. DSA_TAG_PROTO_8021Q abstracts all of that away and the switch netdevices will not need any VLAN sub-interface on top of the master port, and no hardcoding of VLAN trunking over the CPU port either. But then there's the semantics issue - the network stack expects that a bridge with vlan_filtering disabled (the default) passes frames with the 802.1Q EtherType (0x8100) unmodified. It also expects that the switch doesn't perform port membership enforcements based on the VLAN ID. To be compliant, you'll either need to go your route and install the VLANs from userspace (hence you activate vlan_filtering which will means that having a bridge will be a requirement, even the "standalone ports" mode will be emulated), and accept the above limitations, or go with DSA_TAG_PROTO_8021Q and figure out a way that the switch parses and emits VLAN-tagged frames using a different EtherType than the default (case in which the stack will not need to know that the switch is dealing with VLANs as part of its tagging protocol). And when vlan_filtering is enabled, you either have to expose the VLANs used for tagging to the bridge core, or encapsulate the custom tags, or disable tagging. If you choose DSA_TAG_PROTO_8021Q, there is no universal way to ensure the switch treats standard 802.1Q frames distinctly from custom 802.1Q ones - whatever works and is supported by your hardware. Again, with a network stack framework that doesn't rely on the bridge driver (I don't know how OpenWRT/swconfig works), the requirement that the switch obeys the vlan_filtering semantics may be much more lax. For DSA/switchdev, it is what it is. You should also consider that you need Shared VLAN Learning (instead of Independent VLAN Learning) in order not to break address learning and have the switch flood everything. > > For OpenWrt using kernel v4.19 I have no idea what the best would > > be. I don't think Vladimir's work can be easily backported. > > I suppose some special hack to just bring up the DSA with > > a custom script is the best compromise for the time being. > > > > I agree with You. At this moment only hack could work. > > > > FYI this board supported by OpenWrt also has this switch: > > https://openwrt.org/toh/evaluation.boards/pb44 > > with a custom driver: > > https://github.com/openwrt/openwrt/blob/master/target/linux/ar71xx/files/drivers/spi/spi-vsc7385.c > > It's a MIPS device though, and I don't know if anyone is > > actively maintaining it and could test to migrate it to this > > new driver and help out? > > Pb44 isn't ported to ath79 yet. I think, it is abandoned at this moment. > > Best Regards, > Pawel Dembicki Hope this helps, -Vladimir _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel