[Rdo-list] partially broken VLAN tagging support

Perry Myers pmyers at redhat.com
Thu Nov 14 14:38:22 UTC 2013

On 11/14/2013 08:55 AM, Thomas Graf wrote:
> On 11/14/2013 01:26 PM, Matthew Mosesohn wrote:
>> Hi RDO list,
>> There are some serious issues with VLAN tagging in
>> OVS with the current RDO kernel posted here:
>> http://repos.fedorapeople.org/repos/openstack/openstack-grizzly/epel-6/kernel-2.6.32-358.123.2.openstack.el6.x86_64.rpm
>> The issue is that tagged frames get dropped somewhere at the network
>> stack and never actually make it out to the network. These should work
>> natively with this kernel, but we're seeing serious issues. The two
>> specific drivers affected are e1000e and bnx. This applies on just
>> about any 10gigE hardware.
> I cannot confirm this. The majority of 10Ge cards work fine in our
> lab with kernel-2.6.32-358.123.2.openstack.
>> According to this doc, they should work
>> natively without the OVS VLAN splintering hack:
>> https://access.redhat.com/site/articles/289823
> The cards listed on that page have been successfully verified in
> our lab. Please ensure that your network is configured properly.
> OVS will take care of the tagging but it will f.e. not do MVRP.
> Can you confirm that your switch is configured properly, i.e.
> VLANs configured manually or port in trunk mode?
>> There's an old patch we're looking at that may help a bit, but it
>> doesn't apply cleanly.
>> http://openvswitch.org/pipermail/discuss/2011-April/005026.html .
>> We're looking at this code segment in net/8021q/vlan_core.c and are
>> trying to understand why vlan_gro_common changed parameters:
>> EXPORT_SYMBOL(vlan_dev_vlan_
>> id);
>> static gro_result_t
>> vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
>>                  unsigned int vlan_tci, struct sk_buff *skb)
>> I'm told that enabling the OVS splinter mode sometimes causes unwanted
>> behavior and we want to avoid activating it. I was wondering if anyone
>> can comment on this issue and if there's anyone working on a relevant
>> fix.
> I don't know who told you that enabling splinters causes unwanted
> behaviour. It is perfectly fine to do so and a known good workaround
> for buggy drivers.
> All it causes is install a traditional VLAN device on top of physical
> uplinks to trigger VLAN membership in the driver.

Thanks Thomas.

Matty, just in case there is an actual bug behind this, can you please
file a bug here, specifically on the kernel component?


More information about the dev mailing list