Hi Kristoffer, Sorry for late response.
On Tue, Jul 29, 2014 at 4:30 PM, Kristoffer Egefelt <kristof...@itoc.dk> wrote: > I actually asked them: > http://lists.opencontrail.org/pipermail/users_lists.opencontrail.org/2014-July/000338.html > > As I understood it, they are able to offload from VM to VM, without > segmentation - maybe I’m wroing, and what actually is happening is that their > vrouter module, on the receiving side, is able to reassemble the packets to > 64k before sending to the vif. > This reassembly I cannot reproduce with OVS. > Maybe this is how they reach the 9.18Gbps ? > In fact the optimization I mentioned to VXLAN was similar in the way you described. Earlier discussion in OVS community: http://openvswitch.org/pipermail/discuss/2014-May/013981.html The OVS patch in my Github: https://github.com/hzhou8/openvswitch/commit/9a7deb8b432ce83a9c09d7d4ff85fa050f7dd2be RFC draft: http://tools.ietf.org/html/draft-zhou-li-vxlan-soe-01 However this cannot achieve 9+ Gbits/sec for a single flow. It was around 2.5 times increase from 2.6G to 6.7G. Linux kernel had an optimization for GRO and GSO for UDP tunnels, VXLAN is one use case. Should be similar in GRE tunnels. The approach is different but performance gains are similar, because all these solutions are to reassemble in receiving host to avoid small packet to RX VMs. Back to the OpenContrail case, I think they might be using multiple flows instead of one to achieve 9+ Gbits/sec. Without hardware acceleration (disable TSO/GRO on NIC), even with baremetal we can only achieve 6+ Gbits/sec with a single flow. So I don't believe the software offloading of vRouter can compete NIC acceleration. Best regards, Han _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
