[ovs-dev] MPLS and VLAN QinQ patch

ravi kerur rkerur at gmail.com
Thu Jun 14 04:24:54 UTC 2012


On Wed, Jun 13, 2012 at 7:58 PM, Jesse Gross <jesse at nicira.com> wrote:
> On Thu, Jun 14, 2012 at 4:51 AM, ravi kerur <rkerur at gmail.com> wrote:
>> Ok got it. At least I am sensing that OVS will/should be optimized for
>> both core and edge cases. I have taken care of comments from Pravin
>> and I think we are waiting for Ben's input on ttl handling?
>
> It's not a question of optimization.  If you implement something it
> needs to be properly designed and work.  The things you are
> implementing have different use cases so you need to think both about
> those and that fact that OVS/OpenFlow are designed to enable new uses.
>  You must come up with solutions that are flexible and extensible, not
> just ones that address your current use case.

<rk> what are those new use cases? atleast I would like to understand that
>
>> There are additional things that needs to be addressed as well
>>
>> 1. offload code review, it's currently generic enough and getting near
>> line rate performance numbers.
>
> You can't just take what is done for vlans and copy that.  There is
> far too much code that you're adding to OVS.  Did you read what I
> wrote earlier about where to start?:

<rk> How is adding far too much code to ovs related to offload? It is
handled similar to what vlan is doing for older kernel + in addition
it takes care of handling copy + restore skb->protocol since
skb_gso_segment relies on it and handle cases for non-gso packets to
calculate checksum. I don't understand your comments, have you looked
at latest patch?
>
> Generally speaking the emulation code is handled by skb_gso_segment()
> in dev.c in the kernel code outside of OVS.  This should mostly work
> except that it needs to be able to detect that MPLS requires
> emulation.  This will be the easiest part to get working and is the
> best place to start.  However, in order for this code to work on any
> kernel before your changes get integrated (i.e. Linux 3.6 at the
> earliest) you'll have to emulate it in OVS as well, like we do for
> vlans in vport-netdev.c.
>
>> 2. vlan/mpls tunneling in gre or ip, performance numbers are not good.
>> However, using latest git code I tried sending vlan tagged packets on
>> gre tunnel and performance is bad as well. I will have to look into it
>> further because its not yet clear to me why performance would be bad.
>
> I think if you get point #1 working correctly then tunneling
> offloading should just work.

<rk> As i mentioned earlier, can you elaborate your earlier comments?
>
>> Finally, are performance numbers for OVS published or documented?
>
> There would be too much variation between machines to be useful for
> development.  Just run your test on master and compare.

<rk> that's what I did for vlan + gre and performance numbers looked
bad and hence asked the question



More information about the dev mailing list