Re: [E1000-devel] BUG? strange behavior with vlans and virtual functions on i350

[Chris F. <chr...@ge...>]

On 11/13/2012 04:48 PM, Vick, Matthew wrote:

> I took a look at this with Carolyn and I believe what you're seeing
> is the expected behavior. In these older kernels, there was no
> ethtool option to turn on and off VLAN stripping on the fly. If you
> look, the get_flags operation just calls ethtool_op_get_flags, which
> doesn't recognize ETH_FLAG_RXVLAN.

Okay, fair enough.  I realize it's an older kernel. :)

> If you're seeing issues with the functionality of VLANs with igb
> alone, let us know and we'll take a look at it.

What about VLANs when mixing igb/igbvf?  This shouldn't involve ethtool 
options.  It appears that the design intent is that the hardware strips 
off the VLAN tag but passes the information through so that it can be 
passed up the stack on the receiver, but this doesn't seem to be working.

With the older kernel but the latest igb/igbvf drivers we're having 
issues as follows:

We can send vlan-tagged packets from a different system and they are 
received in the VMs just fine.  However, if we try to send vlan-tagged 
packets from one VF to the other it appears that the hardware is 
stripping the VLAN tag information and not passing it through to the 
other VF.

As per my previous emails I can edit the driver to force vlan stripping 
to be disabled and it seems to let it work in certain circumstances (and 
I could probably get it working reliably with a bit of debugging), but I 
shouldn't need to edit the driver to make it work.

I'd appreciate it if you could try the following scenario: host using 
PF, two VMs each using a different VF from that PF.  Everyone is using 
the same VLAN with hardware stripping enabled.  Then test connectivity 
between the two VMs, between host and VM, and from the outside world (on 
the same VLAN) to both host and a VM.

Thanks,
Chris