Message-ID: <CACRpkdYhoUwsAf4RtY46gfsG1QoS8iq9uDVHTPL-64Yz5M0xvw@mail.gmail.com>
Date:   Mon, 4 Mar 2019 10:51:50 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Vladimir Oltean <olteanv@...il.com>, Andrew Lunn <andrew@...n.ch>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 3/3] net: dsa: Add Vitesse VSC73xx DSA router driver

Hi Vladimir,

On Sun, Mar 3, 2019 at 1:08 PM Vladimir Oltean <olteanv@...il.com> wrote:

> I am writing a DSA driver for a switch that doesn't support port separation
> through switch tagging, and came across this discussion.
> Would you mind to share some thoughts on how port separation with
> DSA_TAG_PROTO_NONE would currently work? Thinking about the situations when
> (a) ports are standalone
> (b) ports are bridged with vlan_filtering=0
> (c) ports are bridged with vlan_filtering=1

When VLAN filtering is off it kind of becomes broadcast and all
ports see all ports right? The switch is just "one big phy connected
to an external switch" and with "external switch" I mean one
of those boxes you buy and plug into your network as a
network powerstrip. It gets as dumb as that IIUC.

If all ports on the switch are marked "LAN1", "LAN2" etc
on the device this is kind of fine (IIUC) but if one of them
is marked "WAN" this is definitely not good because what
happens is that your bridge your LAN with the WAN
without any firewall (uh-oh). All my devices with the
Vitesse VSC switches have only "LAN" ports, phew.

With VLAN enabled it can at least start to do some kind of
intelligent things if the user knows how to use the "ip"
command (I don't really, lack of experience).

> I am interested in trying to add generic support for DSA_TAG_PROTO_8021Q that
> would also cover my hardware.

This would be nice, I think Andrew Lunn suggested this in the past
(DSA_TAG_PROTO_VLAN or so) and I looked at it briefly but I'm
not smart enough with VLANs to understand what needs to be
done.

> However I do see some potential limitations, so
> let me quickly describe what it can and cannot do:
> * VLAN filtering cannot be disabled per se in hardware. The switch always
>   internally appends the port-configured pvid to all untagged traffic. If
>   traffic comes tagged, it enforces VLAN membership on the ingress port, and
>   does not append any tag internally but keeps what already was in the frame.
>   Each egress port can be either configured to send tagged or untagged frames.
> * The switch has a programmable TPID by which it can be told what EtherType it
>   should recognize and tag as 802.1Q. Thinking that VLAN filtering disabled can
>   be emulated by configuring its TPID as 0x0 instead of 0x8100.

I think I heard about that trick before.

I also heard about using VLAN 0 which has some undefined properties.

> * It is able to recognize double-tagged frames (802.1ad) via a configurable
>   TPID2, but it cannot actually be configured to push or pop VLAN headers if
>   frames are already tagged on ingress. The only permitted action on frames
>   detected as double-tagged is to optionally drop them.
> * It cannot retag an ingress VLAN ID on ingress with another one on egress.
>   Actually it can, but the feature is for debug purposes and it will actually
>   create a frame clone with the new tag. I would like to avoid using this, as I
>   would have to drop the original frame and it would look bad in port counters.
>
> For my particular hardware, when vlan_filtering is disabled, this custom
> 802.1Q tag with a TPID of 0x0 can be used as a make-shift switch tag, given
> that a unique pvid is applied to each user port, and the upstream port is
> configured in trunk mode (tagged on the egress towards the master).
> When vlan_filtering is enabled, obviously I cannot make use of the 0x0 TPID and
> I have to restore the 802.1Q one. This means that switch tagging can no longer
> work, and port separation has to rely on user configuration.
>
> I did look at RTL8366 and saw that the TPID is not programmable.

Right, it's either 0x8100 or Realtek RRCP funnyspeak if I get it right.

> I'm wondering
> whether a generic solution for DSA_TAG_PROTO_8021Q is indeed possible, and
> looking for your advice on how it would look like.

I was hacking on the RTL8366RB the other day.

Currently it probes default by setting up VLAN 1..6 where these correspond
to ports 0..5, port 5 is the CPU port. 4 ports are LAN one port WAN and
one port CPU. It creates one VLAN per port and makes the CPU port
member of all VLANs and all ports members of the CPU port VLAN.

Port 0 gets VLAN 1, Port 1 gets VLAN 2 etc. The port mask for each
port includes that port itself and the CPU port, and the port mask for
the CPU port is special and includes all ports.

This allows all the ports to talk freely to the CPU port and makes for
isolation between WAN and LAN and the different LAN ports by
default, which is neat.

This set-up is just hard-coded at probe()
drivers/net/dsa/rtl8366.c function rtl8366_init_vlan().

When I say it sets up VLAN it just hard-codes that into the
hardware so the network can be brought up, the kernel at
large and userspace is not aware.

(This was what the vendor driver hack was doing, mind that I don't
even have a datasheet for this ASIC, just an unintelligible code
dump...)

I was thinking that this kind of VLAN setup would be what
DSA_TAG_PROTO_VLAN would do by calling the proper API
VLAN setup calls.

This current setup is problematic because userspace "ip" does
not know about it, and e.g. OpenWrt userspace starts to
"disable filtering" on all ports when it initializes and that is not
quite working. Userspace has no idea that it can't use VLAN
1 thru 6 or how to inspect existing VLANs (IIUC). "ip link show"
shows nothing.

I don't even know where the state of existing VLANs are
stored. I guess in the kernel so DSA_TAG_PROTO_VLAN would
register these VLANs properly and userspace would be able to
see them using "ip link show" as eth0.1, eth0.2, eth0.3 etc
(the CPU port is == eth0).

I have an experimental patch where I use VLAN 0 as "filtering off"
VLAN, so that I can make a port member of VLAN 0 and set pvid
accordingly to emulate "VLAN disabled", as there is no way to
actually disable VLAN filtering on this switch. I didn't submit this
patch because I'm not sure it is a good idea.

Yours,
Linus Walleij

Powered by blists - more mailing lists