[Rdo-list] Engineer interviews from OpenStack Summit
by Rich Bowen
I'd like to do a number of engineer interviews over the coming months
with folks from the RDO community about what they're doing on OpenStack.
Dan Radez and Flavio Percoco were kind enough to be guinea pigs for me
at the OpenStack Summit last week, and those interviews are here:
Flavio: http://drbacchus.com/flavio-percoco-on-openstack-marconi
Dan: http://drbacchus.com/dan-radez-on-openstack
Unfortunately, the sound quality on Dan's is pretty awful because I had
my mic mode selection set wrong.
If you're interested in talking briefly (3-5 minutes) about what you do
on OpenStack, I'd love to set something up with you. Still working on
what's the best way to record online interviews, so the first few might
be a little experimental.
--Rich
--
Rich Bowen - rbowen(a)redhat.com
OpenStack Community Liaison
http://openstack.redhat.com/
11 years
Re: [Rdo-list] partially broken VLAN tagging support
by Perry Myers
On 11/14/2013 10:20 AM, Matthew Mosesohn wrote:
> BZ made
> https://bugzilla.redhat.com/show_bug.cgi?id=1030501
>
> We can reproduce in virtual hardware, but it's not the real thing.
> We'll have access to some broadcom hardware tomorrow and recreate our
> environment.
Thanks!
Perry
> On Thu, Nov 14, 2013 at 6:38 PM, Perry Myers <pmyers(a)redhat.com> wrote:
>> 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/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.
>>>
>>> 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?
>>
>> https://bugzilla.redhat.com/enter_bug.cgi?product=RDO
11 years
