Date:   Sun,  3 Mar 2019 14:08:39 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     linus.walleij@...aro.org, f.fainelli@...il.com
Cc:     netdev@...r.kernel.org, olteanv@...il.com
Subject: Re: [PATCH 3/3] net: dsa: Add Vitesse VSC73xx DSA router driver

On Sat, 30 Jun 2018 13:05:47, Linus Walleij wrote:
> On Thu, Jun 14, 2018 at 6:51 PM Florian Fainelli <f.fainelli@...il.com> wrote:
> > On 06/14/2018 05:35 AM, Linus Walleij wrote:
>
> > > using DSA as a best fit so we can easily add VLAN support and maybe
> > > later also exploit the internal frame header to get more direct
> > > control over the switch.
> >
> > Yes having the internal frame header working would be really great,
> > DSA_TAG_PROTO_NONE is really difficult to use without knowing all the
> > DSA details which reminds that we should have the following action items:
> >
> > - document how DSA_TAG_PROTO_NONE behave differently with respect to
> > bridges/VLAN configuration and the DSA master device
> >
> > - possibly introduce DSA_TAG_PROTO_8021Q which would automatically
> > partition ports by allocating one VLAN ID per-port (e.g: from top to
> > bottom) that would effectively offer the same features/paradigms as what
> > a proper header would offer (Port separation, if nothing else) and it
> > could be made seemingly automatic from within DSA
>
> To me this makes a lot of sense. I haven't implemented VLAN yet
> for this switch chip, but for the Realtek RTL8366RB that I'm also
> working with, the vendor driver already does more or less exactly
> this by default. It would be great to have the kernel just put this
> in place so we have it under control.
>
> The RTL8366 chips does not even seem to have an internal
> frame format AFAICT, it seems they don't know what that is.
> So they will likely always have to use VLAN for this.

Hi Florian, Linus,

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
I am interested in trying to add generic support for DSA_TAG_PROTO_8021Q that
would also cover my hardware. 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.
* 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. 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.

Thank you,
-Vladimir

Powered by blists - more mailing lists