RE: [net-next 02/10] ixgbevf: Fix broken trunk vlan

-----Original Message-----
From: Jesse Gross [mailto:jesse@nicira.com]
Sent: Monday, September 26, 2011 5:54 PM
To: Rose, Gregory V
Cc: Kirsher, Jeffrey T; davem@davemloft.net; netdev@vger.kernel.org;
gospo@redhat.com; Jiri Pirko
Subject: Re: [net-next 02/10] ixgbevf: Fix broken trunk vlan


OK, maybe due to hardware limitations what I'm looking for just really
isn't possible.

From what I can tell that is the case.

 However, what I'm trying to emphasize is that vconfig
is not the only way that vlans can be consumed by the network stack
and active_vlans is just an indication of whether a vlan filter was
set, nothing more (perhaps I should have picked a better name when I
originally designed this stuff).

Understood.  The VF is incapable of receiving VLAN traffic unless a filter has been set.  It doesn't do promiscuous mode and any path that doesn't actually end up setting a VLAN filter won't receive any VLAN traffic.

 In particular, it is not intended to
determine whether a tag should be stripped off or not because
non-vconfig users don't necessarily know which vlans they care about
(think tcpdump or trunking over a bridge).  A major goal of the
existing vlan infrastructure is to avoid having drivers make
assumptions about the consumer of the tag and instead just hand all
information over to the network stack so it can behave in a consistent
manner.  That's why I was looking for alternate ways to get this
information without depending on active_vlans as this driver behaves
quite a bit differently from others, include the ixgbe PF driver.

There are only two paths for the ixgbevf driver to receive VLAN traffic.  Either a VLAN filter has been set, which will result in a bit tag in active_vlans being set or the system administrator in the host VMM has put the VF device in trunk VLAN mode using the 'ip link set <dev> vf <n> <vlanid>' path.  There is no other way for it to receive VLAN traffic, so I think we're fine.  And keep in mind, once the system admin has put the VF device in trunk vlan mode, the VF is no longer allowed, as a policy implemented in the PF driver, to set any other VLAN filters.  Even if it did, it wouldn't work due to the operational characteristics of the VF device HW.

The methods by which the ixgbe driver, as a fully featured Physical Function device, are quite a bit more varied.  I believe you're thinking of the VF device as a typical Ethernet device and that is just not the case.

- Greg