Message-ID: <CA+h21hq6y3aSFQjZQOOx55WQ1q3Cw_r1D72=ij6hkqTtMUhqEg@mail.gmail.com>
Date:   Thu, 21 Nov 2019 20:07:26 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH net-next] net: dsa: tag_8021q: Allow DSA tags and VLAN
 filtering simultaneously

On Thu, 21 Nov 2019 at 19:37, Florian Fainelli <f.fainelli@...il.com> wrote:
>
> On 11/21/19 2:29 AM, Vladimir Oltean wrote:
> > On Mon, 18 Nov 2019 at 06:30, Florian Fainelli <f.fainelli@...il.com> wrote:
> >>
> >> On 11/17/2019 1:14 PM, Vladimir Oltean wrote:
> >> [snip]
> >>
> >>> +best_effort_vlan_filtering
> >
> > [snip]
> >
> >>> +                     - Cannot terminate VLAN-tagged traffic on local device.
> >>> +                       There is no way to deduce the source port from these.
> >>> +                       One could still use the DSA master though.
> >>
> >> Could we use QinQ to possibly solve these problems and would that work
> >> for your switch? I do not really mind being restricted to not being able
> >> to change the default_pvid or have a reduced VLAN range, but being able
> >> to test VLAN tags terminated on DSA slave network devices is a valuable
> >> thing to do.
> >> --
> >> Florian
> >
> > I took another look at the hardware manual and there exists a feature
> > called the Retagging Table whose purpose I did not understand
> > originally. It can do classification on frames with a given { ingress
> > port mask, egress port mask, vlan id }, and clone them towards a given
> > list of destination ports with a new VID. The table only has space for
> > 32 entries though. I think I can use it to keep the CPU copied to all
> > non-pvid VLANs received on the front-panel ports. The CPU will still
> > see a pvid-tagged frame for each of those, but with the PCP from the
> > original frame. The result is that VLAN filtering is still performed
> > correctly (non-member VIDs of the front-panel ports are dropped), but
> > the tag is consumed by DSA and sockets still see those frames as
> > untagged. To me that's fine except for the fact that the CPU will now
> > be spammed by offloaded flows even if the switch learns the
> > destination to be a front-panel. Just wanted to hear your opinion
> > before attempting to prototype this.
>
> That seems like a good idea to me. Back to your RFC patch here, instead
> of introducing a "best effort vlan filtering" configuration knob, how
> about just restricting the possible VID range when vlan_filtering=1
> through the port_vlan_prepare() callback to exclude the problematic
> dsa_tag_8021q VID ranges used for port discrimination?
> --
> Florian

Ugh. I'll have to think about that. The "best effort" vlan_filtering
is a good enough approximation for probably lots of use cases, but if
you just want STP and PTP on your switch (aka traffic that this switch
doesn't need VLANs to decode) and you otherwise need the more advanced
VLAN features (your own pvid, more than 32 VLANs, independent VLAN
learning), then plain vlan_filtering is clearly the better option and
the "best effort" compromises only bring insanity to it.

By the way, I _think_ it's actually possible to retag frames towards
the CPU without even creating clones, but this is very poorly
documented. I really need to experiment a bit.

Thanks,
-Vladimir

Powered by blists - more mailing lists