On 3/23/2019 8:23 PM, Vladimir Oltean wrote:

This patch provides generic DSA code for using VLAN (802.1Q) tags for
the same purpose as a dedicated switch tag for injection/extraction.
It is based on the discussions and interest that has been so far
expressed in https://www.spinics.net/lists/netdev/msg556125.html.

Unlike all other DSA-supported tagging protocols, CONFIG_NET_DSA_TAG_8021Q
does not offer a complete solution for drivers (nor can it). Instead, it
provides generic code that driver can opt into calling:
- dsa_8021q_xmit: Inserts a VLAN header with the specified contents.
  Currently a few driver are inserting headers that are simply 802.1Q
  with custom fields. Can be called from another tagging protocol's xmit
  function.
- dsa_8021q_rcv: Retrieves the TPID and TCI from a VLAN-tagged skb.
  Removing the VLAN header is left as a decision for the caller to make.
- dsa_port_setup_8021q_tagging: For each user port, installs an Rx VID
  and a Tx VID, for proper untagged traffic identification on ingress
  and steering on egress. Also sets up the VLAN trunk on the upstream
  (CPU or DSA) port. Drivers are intentionally left to call this
  function explicitly, depending on the context and hardware support.
  The expected switch behavior and VLAN semantics should not be violated
  under any conditions. That is, after calling
  dsa_port_setup_8021q_tagging, the hardware should still pass all
  ingress traffic, be it tagged or untagged.

This only works when switch ports are standalone, or when they are added
to a VLAN-unaware bridge. It will probably remain this way for the
reasons below.

When added to a bridge that has vlan_filtering 1, the bridge core will
install its own VLANs and reset the pvids through switchdev. For the
bridge core, switchdev is a write-only pipe. All VLAN-related state is
kept in the bridge core and nothing is read from DSA/switchdev or from
the driver. So the bridge core will break this port separation because
it will install the vlan_default_pvid into all switchdev ports.

Even if we could teach the bridge driver about switchdev preference of a
certain vlan_default_pvid, there would still exist many other challenges.

Firstly, in the DSA rcv callback, a driver would have to perform an
iterative reverse lookup to find the correct switch port. That is
because the port is a bridge slave, so its Rx VID (port PVID) is subject
to user configuration. How would we ensure that the user doesn't reset
the pvid to a different value, or to a non-unique value within this DSA
switch tree?

Finally, not all switch ports are equal in DSA, and that makes it
difficult for the bridge to be completely aware of this anyway.
The CPU port needs to transmit tagged packets (VLAN trunk) in order for
the DSA rcv code to be able to decode source information.
But the bridge code has absolutely no idea which switch port is the CPU
port, if nothing else then just because there is no netdevice registered
by DSA for the CPU port.

That is true, although we can use the bridge master device as a
substitute for targeting the CPU port (we don't have any for the DSA
ports though, so they will have to remain in a mode where they forward
all VIDs), see .

We don't support that just yet in DSA though.

Also DSA does not currently allow the user to specify that they want the
CPU port to do VLAN trunking anyway. VLANs are added to the CPU port
using the same flags as they were added on the user port.

So the VLANs installed by dsa_port_setup_8021q_tagging per driver
request should remain private from the bridge's and user's perspective,
and should not alter the hardware's behavior with VLAN-tagged traffic.
If the hardware cannot handle VLAN tag stacking, it should also disable
this port separation when added as slave to a vlan_filtering bridge.
If the hardware does support VLAN tag stacking, it should somehow back
up its private VLAN settings when the bridge tries to override them.

This is an excellent commit message and it captures really well the
challenges involved in trying to coerce 802.1Q only switches into
offering separate DSA slave network devices. Here are a few ideas on how
this can be solved now or later, with possibly a reduction in functionality:

- if the switch internally performs double VLAN tag normalization, then
we could dedicate an outer tag per bridge device, which would allow
identical inner tag VID numbers to co-exist, yet preserve broadcast
domain isolation

- when only 802.1Q is supported (single tagging), we could somehow
enforce that all ports must be part of a VLAN aware bridge, which would
eliminate the need to have standalone DSA network devices alongside
bridged DSA network devices

Your solution clearly works and is a clever way to solve that problem.

[snip]

+config NET_DSA_TAG_8021Q
+	bool
+	help

This probably needs a depends on/select VLAN_8021Q to be functional.

VLAN_N_VID may not be a range supported on all switches (e.g.: the ones
that were once popular 15 years ago, like BCM5325/5365) but that can be
changed later on to incorporate per-switch VLAN range limitations.

I would add a comment about why you reserving two times the space, for
which you provide an explanation down below.


With the Kconfig changed:

Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian