[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 10 Oct 2015 07:49:11 +0000
From: Elad Raz <eladr@...lanox.com>
To: Vivien Didelot <vivien.didelot@...oirfairelinux.com>
CC: Jiri Pirko <jiri@...nulli.us>, Scott Feldman <sfeldma@...il.com>,
netdev <netdev@...r.kernel.org>,
"stephen@...workplumber.org" <stephen@...workplumber.org>,
Florian Fainelli <f.fainelli@...il.com>,
Andrew Lunn <andrew@...n.ch>,
Ido Schimmel <idosch@...lanox.com>,
"Or Gerlitz" <ogerlitz@...lanox.com>
Subject: Re: switchdev and VLAN ranges
> On Oct 10, 2015, at 2:30 AM, Vivien Didelot <vivien.didelot@...oirfairelinux.com> wrote:
>
> I have two concerns in mind:
>
> a) if we imagine that drivers like Rocker allocate memory in the prepare
> phase for each VID, preparing a range like 100-4000 would definitely not
> be recommended.
>
> b) imagine that you have two Linux bridges on a switch, one using the
> hardware VLAN 100. If you request the VLAN range 99-101 for the other
> bridge members, it is not possible for the driver to say "I can
> accelerate VLAN 99 and 101, but not 100". It must return OPNOTSUPP for
> the whole range.
Another concern I have with vid_being..vid_end range is the “flags”. Where flags can be BRIDGE_VLAN_INFO_PVID.
There is no sense having more than one VLAN as a PVID.
This leave the HW vendor the choice which VLAN id they will use as the PVID.
Powered by blists - more mailing lists