On Wed, 21 Aug 2019 at 00:36, Vivien Didelot <vivien.dide...@gmail.com> wrote:
>
> On Wed, 21 Aug 2019 00:02:22 +0300, Vladimir Oltean <olte...@gmail.com> wrote:
> > On Tue, 20 Aug 2019 at 23:58, Vivien Didelot <vivien.dide...@gmail.com>
> > wrote:
> > >
> > > On Tue, 20 Aug 2019 23:40:34 +0300, Vladimir Oltean <olte...@gmail.com>
> > > wrote:
> > > > 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.
> > >
> > > What do you mean by getting rid of the vlan bitmap? What do you need
> > > exactly?
> >
> > It would be nice to configure the VLAN attributes of the CPU port in
> > another way than the implicit way it is done currently. I don't have a
> > specific use case right now.
>
> So you mean you need a lower level API to configure VLANs on a per-port basis,
> without any logic, like including CPU and DSA links, etc.
>
> The bitmap operations were introduced to simplify the switch drivers in the
> future, since most of them could implement the VLAN operations (add, del)
> in simple functions taking all local members at once.
>
> But the Linux interface being exclusively based on a per port (slave) logic,
> it is hard to implement right now.
>
> The thing is that CPU ports, as well as DSA links in a multi-chip setup,
> need to be programmed transparently when a given user port is configured,
> hence the notification sent by a port to all switches of the fabric.
>
> So I'm not against removing the bitmap logic, actually I'm looking into it
> as well as moving more bridge checking logic into the slave code itself,
> because I'm not a fan of your "Allow proper internal use of VLANs" patch.
>
> But you'll need to provide more than "it would be nice" to push in that
> direction, instead of making changes everywhere to make your switch work.
>
>
> Thanks,
>
> Vivien
I mean I made an argument already for the hack in 4/6 ("Don't program
the VLAN as pvid on the upstream port"). If the hack gets accepted
like that, I have no further need of any change in the implicit VLAN
configuration. But it's still a hack, so in that sense it would be
nicer to not need it and have a better amount of control.
