Hi Florian, On Tue, 20 Aug 2019 at 22:40, Florian Fainelli <f.faine...@gmail.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 <olte...@gmail.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
