2015-10-10 0:01 GMT-07:00 Jiri Pirko <j...@resnulli.us>: > Sat, Oct 10, 2015 at 05:20:28AM CEST, sfel...@gmail.com wrote: >>On Fri, Oct 9, 2015 at 3:44 PM, Vivien Didelot >><vivien.dide...@savoirfairelinux.com> wrote: >>> Hi Jiri, >>> >>> On Oct. Friday 09 (41) 01:54 PM, Jiri Pirko wrote: >>>> From: Jiri Pirko <j...@mellanox.com> >>>> >>>> Some drivers need to implement both switchdev vlan ops and >>>> vid_add/kill ndos. For that to work in bridge code, we need to try >>>> switchdev op first when adding/deleting vlan id. >>> >>> Just curious, when would a driver need to have both operations? >> >>Ya, I was kind of curious of that myself. Is this because the driver >>wants to support standalone VLANs using 802.1q module and vconfig, as >>well as bridge vlans? With the vlan support built into the bridge, >>I've been working under the assumption that 802.1q module (and >>vconfig) aren't needed, and vlans for a bridged and non-bridge port >>can be managed using the "bridge" iproute2 cmd. > > Sure, but this is for standalone port device, without being bridged. In > that case if you want to use vlan on top of that, you need these ndos.
Standalone VLAN configuration (that is, using vconfig/802.1q module) is fairly limited, and only really makes sense, in its current implementation for a host. By that, I mean, that we cannot configure what is your default VLAN (the untagged one), and it does not matter in the case of a host, because this is something that the other end: the switch, has to have configured for you. For netdevices from a switch device, I think we should really either have the ability to use the same configuration flexibility as the bridge VLAN filtering offers (setting PVID, untagged/default VLAN, tagged), either outside of the bridge layer (which could be of limited use), or just enforce the need of a bridge device to span these specific ports of a switch. -- Florian -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
