Re: [Qemu-devel] [PATCH] net: QEMU_NET_PACKET_FLAG_MORE introduced

[Vincenzo Maffione]

I totally agree with you, and we will propose a patch to make this possible.

However, none of the offloadings you mentioned helps with packet rate throughput (checksum offload doesn't really help with short packets), which is the main purpose of this patch. High packet rates (say 1-5 Mpps) are interesting for people who want to use VMs as middleboxes. These packet rates (and up to 20+ Mpps) are possible with netmap if proper batching is supported.

If you don't think adding the new flag support for virtio-net is a good idea (though TAP performance is not affected in every case) we could also make it optional.

Cheers

  Vincenzo

2013/12/9 Michael S. Tsirkin <address@hidden>

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

--
Vincenzo Maffione