On Mon, Dec 09, 2013 at 11:20:29AM +0100, Vincenzo Maffione wrote: > Hello, > I've done some netperf TCP_STREAM and TCP_RR virtio-net tests, using the > same configuration. > Here are the results > > ########## netperf TCP_STREAM ########### > NO BATCHING BATCHING > 1 5.5 Gbps 3.8 Gbps > 2 5.4 Gbps 5.5 Gbps > 3 5.2 Gbps 5.2 Gbps > 4 5.1 Gbps 5.0 Gbps > 10 5.4 Gbps 5.2 Gbps > 20 5.4 Gbps 5.4 Gbps > > > ############ netperf TCP_RR ############# > NO BATCHING BATCHING > 1 13.0 Ktts 12.8 Ktts > 2 23.8 Ktts 23.0 Ktts > 3 34.0 Ktts 32.5 Ktts > 4 44.5 Ktts 41.0 Ktts > 10 97.0 Ktts 93.0 Ktts > 15 122.0 Ktts 120.0 Ktts > 20 125.0 Ktts 128.0 Ktts > 25 128.0 Ktts 130.0 Ktts > > > There is some negative effects introduced by batching. > Also consider that > - Since TAP backend doesn't use the new flag, this patch doesn't change the > performance when the TAP backend is used. > - I've not submitted yet the patch for virtio_net_header support, and > therefore the TCP_STREAM performance with NETMAP backend is now not > comparable to the performance with TAP backend, because we are limited to > 1.5KB packets. > > Cheers, > Vincenzo
Ah, so no GSO/UFO/checksum offload then? In that case maybe it's a good idea to start with supporting that in your backend. This does batching within the guest so extra host side batching with all the tradeoffs it involves might not be necessary. Guest network stack behaviour with and without offloads is different to such a degree that it's not clear optimizing one is not pessimizing the other. -- MST
