[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+h21hqdXP1DnCxwuZOCs4H6MtwzjCnjkBf3ibt+JmnZMEFe=g@mail.gmail.com>
Date: Tue, 20 Aug 2019 23:40:34 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Vivien Didelot <vivien.didelot@...il.com>,
Andrew Lunn <andrew@...n.ch>, Ido Schimmel <idosch@...sch.org>,
Roopa Prabhu <roopa@...ulusnetworks.com>,
nikolay@...ulusnetworks.com,
"David S. Miller" <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next 3/6] net: dsa: Delete the VID from the upstream
port as well
Hi Florian,
On Tue, 20 Aug 2019 at 22:40, Florian Fainelli <f.fainelli@...il.com> wrote:
>
> On 8/20/19 10:52 AM, Vivien Didelot wrote:
> > Hi Vladimir,
> >
> > On Tue, 20 Aug 2019 12:54:44 +0300, Vladimir Oltean <olteanv@...il.com> wrote:
> >> I can agree that this isn't one of my brightest moments. But at least
> >> we get to see Cunningham's law in action :)
> >> When dsa_8021q is cleaning up the switch's VLAN table for the bridge
> >> to use it, it is good to really clean it up, i.e. not leave any VLAN
> >> installed on the upstream ports.
> >> But I think this is just an academical concern at this point. In
> >> vlan_filtering mode, the CPU port will accept VLAN frames with the
> >> dsa_8021q ID's, but they will eventually get dropped due to no
> >> destination. The real breaker is the pvid change. If something like
> >> patch 4/6 gets accepted I will drop this one.
> >
> > I wish Ward had mentioned to submit such academical concern as RFC :)
> >
> > Please submit smaller series, targeting a single functional problem each,
> > with clear and detailed messages.
>
> Also, I don't think this change set is useful per-se, if we take care of
> removing VLANs on user facing ports, and VLAN filtering is turned on,
> then a frame ingressing an user port with a VLAN that is not part of the
> VLAN table/entries should simply be discarded on ingress, or on egress
> to the CPU port (depending on where the switch performs VID checking),
> so the CPU port cannot possibly receive such a frame, and so removing it
> from the CPU port is correct from a reference counting perspective, but
> useless in practice. Thoughts?
I don't need this patch. I'm not sure what my thought process was at
the time I added it to the patchset.
I'm still interested in getting rid of the vlan bitmap through other
means (picking up your old changeset). Could you take a look at my
questions in that thread? I'm not sure I understand what the user
interaction is supposed to look like for configuring CPU/DSA ports.
> --
> Florian
Thanks,
-Vladimir
Powered by blists - more mailing lists