On 11/7/14 8:50 AM, Pravin Shelar wrote:
On Thu, Nov 6, 2014 at 12:21 PM, Lori Jakab <loja...@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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
