On Wed, Jan 06, 2021 at 07:08:18PM +0200, Ido Schimmel wrote:
> On Wed, Jan 06, 2021 at 03:09:57PM +0200, Vladimir Oltean wrote:
> > Let's go off and finish the job of commit 29ab586c3d83 by deleting the
> > bogus iteration through the VLAN ranges from the drivers. Some aspects
> > of this feature never made too much sense in the first place. For
> > example, what is a range of VLANs all having the BRIDGE_VLAN_INFO_PVID
> > flag supposed to mean, when a port can obviously have a single pvid? The
> > switchdev drivers have so far interpreted this to mean that the last
> > VLAN in the range should be the only one which should get programmed
> > with that attribute.
>
> See commit 6623c60dc28e ("bridge: vlan: enforce no pvid flag in vlan
> ranges")
No, I agree, but still it changes nothing in terms of the hoops that a
driver must go through. It should still only program vlan->vid_end as
pvid either way. Which is strikingly odd.
> > Of the existing switchdev pieces of hardware, it appears that only
> > Mellanox Spectrum supports offloading more than one VLAN at a time.
> > I have kept that code internal to the driver, because there is some more
> > bookkeeping that makes use of it, but I deleted it from the switchdev
> > API. But since the switchdev support for ranges has already been de
> > facto deleted by a Mellanox employee and nobody noticed for 4 years, I'm
> > going to assume it's not a biggie.
>
> Which code are you referring to?
mlxsw_sp_port_vlan_set
> For the switchdev and mlxsw parts:
>
> Reviewed-by: Ido Schimmel <ido...@nvidia.com>
>
> I applied the series to our queue, so I should have regression results
> tomorrow
Thanks. Could you wait for me to send a v3 though, with that small fixup
in mv88e6xxx? I'm sure it will raise some red flags for your testing too.
