[ovs-discuss] OVS DPDK performance for TCP traffic versus UDP
Michael Richardson
mcr at sandelman.ca
Thu Oct 4 15:01:51 UTC 2018
Onkar Pednekar <onkar3006 at gmail.com> wrote:
> I have been experimenting with OVS DPDK on 1G interfaces. The system
> has 8 cores (hyperthreading enabled) mix of dpdk and non-dpdk capable
> ports, but the data traffic runs only on dpdk ports.
> DPDK ports are backed by vhost user netdev and I have configured the
> system so that hugepages are enabled, CPU cores isolated with PMD
> threads allocated to them and also pinning the VCPUs.
> When I run UDP traffic, I see ~ 1G throughput on dpdk interfaces with <
> 1% packet loss. However, with tcp traffic, I see around 300Mbps
What size packet?
What's your real pps?
What do you do for test traffic?
What is your latency? Are there queues full?
Are you layer-2 switching or layer-3 routing, or something exotic?
> thoughput. I see that setting generic receive offload to off helps, but
> still the TCP thpt is very less compared to the nic capabilities. I
> know that there will be some performance degradation for TCP as against
> UDP but this is way below expected.
Receive offload should only help if you are terminating the TCP flows.
I could well see that it would affect a switching situation significantly.
What are you using for TCP flow generation? Are you running real TCP
stacks with window calculations and back-off, etc? Is your offered load
actually going up?
> I don't see any packets dropped for tcp on the internal VM (virtual)
> interfaces.
?virtual?
I don't understand: do you have senders/receivers on the machine under test?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.openvswitch.org/pipermail/ovs-discuss/attachments/20181004/dbeb9dd3/attachment.sig>
More information about the discuss
mailing list