Date:   Mon, 25 Mar 2019 19:21:37 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>, davem@...emloft.net,
        netdev@...r.kernel.org
Cc:     andrew@...n.ch, vivien.didelot@...il.com, linus.walleij@...aro.org
Subject: Re: [RFC PATCH net-next 05/13] net: dsa: Optional VLAN-based port
 separation for switches without tagging



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.

> @@ -0,0 +1,185 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2019, Vladimir Oltean <olteanv@...il.com>
> + */
> +#include <linux/if_bridge.h>
> +#include <linux/if_vlan.h>
> +
> +#include "dsa_priv.h"
> +
> +#define DSA_TAGGING_VID_RANGE    (DSA_MAX_SWITCHES * DSA_MAX_PORTS)
> +#define DSA_TAGGING_VID_BASE     (VLAN_N_VID - 2 * DSA_TAGGING_VID_RANGE - 1)

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@...il.com>
-- 
Florian

Powered by blists - more mailing lists