Re: [Rdo-list] partially broken VLAN tagging support
by Andrey Korolyov
Hello,
sorry in advance for potential top-posting
On 11/14/2013 06:03 PM, Matthew Mosesohn wrote:
> ---------- Forwarded message ----------
> From: Thomas Graf <tgraf(a)redhat.com>
> Date: Thu, Nov 14, 2013 at 5:55 PM
> Subject: Re: partially broken VLAN tagging support
> To: Matthew Mosesohn <mmosesohn(a)mirantis.com>
> Cc: rdo-list(a)redhat.com
>
>
> 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/ke...
>>
>> 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.
>
Because of my ugly english Matt understood me a bit incorrect - vlan
splinters are okay but table above from redhat.com suggests that almost
everything should work even without specifying a set of VLAN tags and
vlan-splinters at all which is seemingly not true for our lab tests with
same RDO kernel. So question is if we can avoid using any hacks for
specified drivers in the upcoming releases of RDO kernel by small amount
of patchwork or not.
> All it causes is install a traditional VLAN device on top of physical
> uplinks to trigger VLAN membership in the driver.
>
10 years, 5 months
