[OpenWrt-Devel] [PATCH v2] gemini: Bring up DSA switches

[Vladimir Oltean]

Hi Pawel, Linus,

On Fri, 19 Jul 2019 at 12:22, Paweł Dembicki <paweldembicki at gmail.com> wrote:
>
> > On Fri, Jul 19, 2019 at 09:51 Linus Walleij <linus.walleij at 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 at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel