Message-ID: <CA+h21hr7+HX64XGHY-LCZXkLLk3dGxx8JnALHTc=+Phvx=LU0Q@mail.gmail.com>
Date:   Mon, 4 Mar 2019 14:14:04 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 3/3] net: dsa: Add Vitesse VSC73xx DSA router driver

On Mon, 4 Mar 2019 at 11:52, Linus Walleij <linus.walleij@...aro.org> wrote:
>
> Hi Vladimir,

Hi Linus,

>
> 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.
>

I may be in error, but I don't think we have the same understanding of what
VLAN filtering is. As far as I understand, no VLAN filtering means that
hardware is required to not parse, push or pop VLAN tags in whatever frames
it receives or sends (tagged or not). Conversely, VLAN filtering enabled means
hardware is required to parse VLAN information and enforce port membership.

Now, this is orthogonal to forwarding, in a way. I believe that if you want
to isolate two front-panel ports from other two front-panel ports (be they WAN
or LAN), you would want to add them to different bridges (br0 and br1).
But indeed forwarding domain can also be limited using VLAN. In this case a
frame will be passed from one port to another based on a compound decision
(L2 forwarding rules allow AND VLAN port membership domain allows). You would
want to use VLAN when you want a single port to be a member of multiple
domains, because you can't put a single netdevice (front-panel switch port)
in multiple bridges.
All I'm really saying is that I don't think that inside the port_bridge_join
callback, configuring forwarding based on VLAN is a sane thing to do.

I do see that neither vitesse-vsc73xx nor rtl8366 do implement the bridge
membership callbacks, and as I don't happen to know nearly enough about DSA, I
wonder at what moment in time does forwarding get activated between ports.

> 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.

I was really talking about making the TPID 0x0 here and not VID:

+--------+---+---+------- +
|  TPID  |PCP|DEI|   VID  |
+--------+---+---+--------+

As you know, TPID overlaps with EtherType field which has various meanings.
When it's smaller than ETH_P_802_3_MIN (include/uapi/linux/if_ether.h), the
EtherType is taken to mean 'frame length' - an obsolete interpretation of the
field. Hence my proposal was to actually hijack an EtherType that otherwise
means 'this Ethernet frame has a length of zero', and collect some feedback on
the sanity of this idea.

>
> > * 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 don't know with exact certainty but if I were to guess, I'd say the generic
bridge driver keeps VLAN membership information (that you see in 'bridge vlan
show'). And here is where the conundrum is. If one creates a bridge using
'ip link add name br0 type bridge vlan_filtering 0', then when you add the
switch ports to it, the bridge code will never attempt to install VLANs into
it. So switch tagging with 802.1Q would only work when vlan_filtering is
active. With vlan_filtering, I don't see it as a hard thing to achieve given my
current understanding (there need to be as many VLAN sub-interfaces on the
master port as there are front-panel switch ports).
The difficulty is what to do when userspace explicitly requests that switch
should not get smart about VLANs (vlan_filtering 0).
In my previous email, I explained that my hardware's architecture actually
prevents me from avoiding being smart with VLANs (the TPID 0x0 thing). I can
actually make use of that pseudo-VLAN tag even when vlan_filtering is 0
(because technically it's not real VLAN TPID). So the question is not about
myself but about the general case.

> 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.
>

What happens if you receive tagged frames using one of VLANs 1, 2, 3, 4, 5, 6?
Is the VLAN tag removed on egress, or used in any way? If it is, I don't
believe that vlan_filtering is truly disabled then.

Powered by blists - more mailing lists