[ovs-dev] [PATCH v6 3/3] datapath: add layer 3 flow/port support

Lori Jakab lojakab at cisco.com
Mon Nov 10 12:00:42 UTC 2014


On 11/7/14 8:50 AM, Pravin Shelar wrote:
> On Thu, Nov 6, 2014 at 12:21 PM, Lori Jakab <lojakab at cisco.com> wrote:
>> On 11/6/14 4:06 AM, Pravin Shelar wrote:
>>>>> Have you tried running GSO traffic over lisp using OVS compat GSO code
>>>>> and upstream GSO code?
>>>>
>>>> I haven't and I'm not sure what's the right way to do that.  I do my
>>>> testing
>>>> between to VMs.  I see with ethtool that GSO is enabled on the virtual
>>>> NICs
>>>> in the VMs, and on the br0 interface after the switch is created.
>>>>
>>> This is fine.
>>>
>>>> To test that I can enable/disable GSO I download a 30MB file over HTTP
>>>> and
>>>> look in Wireshark for packets satisfying "ip.len > 1500".  With TSO
>>>> enabled,
>>>> I do get such packets.  Not with GSO though.
>>>>
>>>> Can you point me to the right way to test this?
>>> netperf test will to the trick, But you need to test with different
>>> kernel versions.
>>> - kernel < 3.10 where ovs configure could not find symbol
>>> "gre_handle_offloads"
>>> - kernel 3.17 which has all the offload used by OVS.
>>
>> I have one VM with Fedora 18 and kernel 3.7.2-201.fc18.x86_64, and the other
>> with Fedora 19 and kernel 3.14.19-100.fc19.x86_64.  I tried netperf in both
>> directions.  In both cases the OVS + LISP performance vs. direct link
>> performace was one order of magnitude worse.  Is that to be expected?  Is
>> this a good enough test for GSO traffic?  If yes, I will send out v7.
>>
> Can you give me numbers the you are seeing? One way to test GSO is to
> look for any dropped packet at source, tcpdump can help with that. You
> also need to set physical MTU large enough for encapsulated packet.

I found packet loss unrelated to GSO, I need to add layer 3 support to 
ovs_packet_cmd_execute() as well.  I'll get back to you after I finish 
this and I'm able to do the tests.




More information about the dev mailing list