Description of problem: Instances on OVS DPDK currently cannot enable TSO (TCP segment offload), which greatly lowers their performance, making OVS-DPDK possibly a worse choice than not using it at all. The way we test with iperf3 is using TCP protocol, and currently DPDK doesn’t support TSO (TCP Segmentation offload) based on this link: https://bugs.launchpad.net/devstack/+bug/1651727 DPDK: Inter VM communication of iperf3 TCP throughput is very low on same host compare to non DPDK throughput The root cause of the issue is that currently ovs-dpdk does not support TSO offload. With the offload enable, the throughput will be lower than traditional path. In my opinion, we'd need to get the following into OVS-DPDK ASAP: https://mail.openvswitch.org/pipermail/ovs-dev/2016-June/316414.html https://ovs2016.sched.com/event/8aZf/optimizing-communications-grade-tcp-workloads-in-an-ovs-based-nfv-deployment-mark-kavanagh-intel https://www.youtube.com/watch?v=hEP0_Bd3wrA Thanks, Andreas
Adding Yogi to this BZ to understand the feature, impact on installer if any and possible documentation from NFV-DFG that might be required for tuning/perf evaluation.
Intel followed up with a new patchset here: https://mail.openvswitch.org/pipermail/ovs-dev/2019-September/362573.html I proposed another approach, which is much less intrusive to OvS and doesn't have any performance impact on MTU-sized packets: https://mail.openvswitch.org/pipermail/ovs-dev/2019-September/362881.html
Patch posted to DPDK dev: http://mails.dpdk.org/archives/dev/2019-October/145593.html
The patch in comment#25 is merged. I found a csum bug while working on the OvS side, fixed posted: http://mails.dpdk.org/archives/dev/2019-October/148718.html OvS side: The draft patch shows 3.3x gain when pushing from VM to an external host and 3.5x between VMs in the same host. ovs-tcpdump is working as well. fbl
Posted upstream for review (proposed as experimental feature) https://mail.openvswitch.org/pipermail/ovs-dev/2019-December/365350.html
Posted v3 today: https://mail.openvswitch.org/pipermail/ovs-dev/2020-January/366673.html
Note to myself: from Ciara on the Mailing list: TSO appears to be broken for some cases on i40e: https://bugs.dpdk.org/show_bug.cgi?id=373 Patch: https://github.com/Mic92/dpdk/commit/2dc9b8dd2c8e2eb71f216b5b9222a4deb57482c9
Current status: The TSO patchset has been merged for OvS 2.13 as experimental and it works with physical and vhost-user ports along with veth and tap ports. However, there is no fall back in software which means that there is no support for mixing ports with and without TSO. Therefore, all VMs need to support TSO enabled at this point.
The initial support is included in 2.13 as experimental. It still needs encapsulation support and having ports with TSO disabled, so moving back to assigned.
*** Bug 1820296 has been marked as a duplicate of this bug. ***
This missed the Nov 25th deadlinet o be included in OSP 17, needs to go through the exception process to be included in OSP17 from here.
Removing the rhos-18.0 flag as this RFE has no PM or QE acks. Please add the correct acks to retarget this bug to OSP 18
Hello Gurpreet, the full TSO patch set hasn't been accepted into upstream yet.