qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Vincenzo Maffione <v.maffione@gmail.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Jason Wang" <jasowang@redhat.com>,
	mjt@tls.msk.ru, qemu-devel@nongnu.org, lcapitulino@redhat.com,
	peter.crosthwaite@petalogix.com,
	"Dmitry Fleytman" <dmitry@daynix.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Yan Vugenfirer" <yan@daynix.com>,
	"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
	akong@redhat.com, quintela@redhat.com,
	"Alexander Graf" <agraf@suse.de>,
	aliguori@amazon.com, marcel.a@redhat.com, sw@weilnetz.de,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Giuseppe Lettieri" <g.lettieri@iet.unipi.it>,
	"Luigi Rizzo" <rizzo@iet.unipi.it>,
	mark.langsdorf@calxeda.com, owasserm@redhat.com,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH] net: QEMU_NET_PACKET_FLAG_MORE introduced
Date: Mon, 9 Dec 2013 13:14:31 +0200	[thread overview]
Message-ID: <20131209111431.GG15055@redhat.com> (raw)
In-Reply-To: <CA+_eA9iqS2ZEVcPERjfAirRO6EuhdWGF8MpRsk-ucAy27paGZw@mail.gmail.com>

On Mon, Dec 09, 2013 at 11:55:57AM +0100, Vincenzo Maffione wrote:
> 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.

I don't see why would host batching be effective where guest batching
isn't. At least in theory, batching belongs at endpoints not in the
network.

GSO makes packets bigger, and checksum offload helps there.

> 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
> 

I think it's too early to say whether this patch is benefitial for
netmap, too.  It looks like something that trades off latency
for throughput, and this is a decision the endpoint (VM) should
make, not the network (host).
So you should measure with offloads on before you make conclusions about it.



> 2013/12/9 Michael S. Tsirkin <mst@redhat.com>
> 
>     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

  reply	other threads:[~2013-12-09 11:11 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-06 14:44 [Qemu-devel] [PATCH] net: QEMU_NET_PACKET_FLAG_MORE introduced Vincenzo Maffione
2013-12-06 16:39 ` Stefan Weil
2013-12-08 12:11 ` Michael S. Tsirkin
2013-12-09 10:20   ` Vincenzo Maffione
2013-12-09 10:30     ` Michael S. Tsirkin
2013-12-09 10:55       ` Vincenzo Maffione
2013-12-09 11:14         ` Michael S. Tsirkin [this message]
2013-12-09 12:42           ` Stefan Hajnoczi
2013-12-09 13:25             ` Vincenzo Maffione
2013-12-09 14:00               ` Michael S. Tsirkin
2013-12-09 16:04                 ` Vincenzo Maffione
2013-12-09 13:55             ` Michael S. Tsirkin
2013-12-10  9:16               ` Stefan Hajnoczi
2013-12-09 12:36 ` Stefan Hajnoczi
2013-12-09 14:02   ` Michael S. Tsirkin
2013-12-09 14:10     ` Luigi Rizzo
2013-12-10  8:53     ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131209111431.GG15055@redhat.com \
    --to=mst@redhat.com \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=akong@redhat.com \
    --cc=aliguori@amazon.com \
    --cc=dmitry@daynix.com \
    --cc=edgar.iglesias@gmail.com \
    --cc=g.lettieri@iet.unipi.it \
    --cc=jasowang@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=marcel.a@redhat.com \
    --cc=mark.langsdorf@calxeda.com \
    --cc=mjt@tls.msk.ru \
    --cc=owasserm@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.crosthwaite@petalogix.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=rizzo@iet.unipi.it \
    --cc=stefanha@redhat.com \
    --cc=sw@weilnetz.de \
    --cc=v.maffione@gmail.com \
    --cc=yan@daynix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).