[Rdo-list] partially broken VLAN tagging support

[Thomas Graf]

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.