From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33675) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VpykA-0006jy-80 for qemu-devel@nongnu.org; Mon, 09 Dec 2013 06:11:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vpyk2-0008Hn-Lo for qemu-devel@nongnu.org; Mon, 09 Dec 2013 06:11:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51114) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vpyk2-0008Hj-Dk for qemu-devel@nongnu.org; Mon, 09 Dec 2013 06:11:10 -0500 Date: Mon, 9 Dec 2013 13:14:31 +0200 From: "Michael S. Tsirkin" Message-ID: <20131209111431.GG15055@redhat.com> References: <1386341073-6584-1-git-send-email-v.maffione@gmail.com> <20131208121117.GD6841@redhat.com> <20131209103026.GC15055@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] net: QEMU_NET_PACKET_FLAG_MORE introduced List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vincenzo Maffione Cc: Peter Maydell , Jason Wang , mjt@tls.msk.ru, qemu-devel@nongnu.org, lcapitulino@redhat.com, peter.crosthwaite@petalogix.com, Dmitry Fleytman , Gerd Hoffmann , Yan Vugenfirer , "Edgar E. Iglesias" , akong@redhat.com, quintela@redhat.com, Alexander Graf , aliguori@amazon.com, marcel.a@redhat.com, sw@weilnetz.de, Stefan Hajnoczi , Giuseppe Lettieri , Luigi Rizzo , mark.langsdorf@calxeda.com, owasserm@redhat.com, Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= 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 poss= ible. >=20 > However, none of the offloadings you mentioned helps with packet rate > throughput (checksum offload doesn't really help with short packets), w= hich 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 sup= ported. 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 ma= ke it > optional. >=20 >=20 > Cheers > =A0 Vincenzo >=20 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 >=20 > On Mon, Dec 09, 2013 at 11:20:29AM +0100, Vincenzo Maffione wrote: > > Hello, > > =A0=A0 I've done some netperf TCP_STREAM and TCP_RR virtio-net te= sts, using > the > > same configuration. > > Here are the results > > > > ########## netperf TCP_STREAM ########### > > =A0=A0=A0=A0=A0=A0=A0 NO BATCHING=A0=A0=A0=A0=A0=A0=A0=A0 BATCHIN= G > > 1=A0=A0=A0=A0=A0=A0=A0=A0=A0 5.5 Gbps=A0=A0=A0=A0=A0=A0=A0=A0 3.8= Gbps > > 2=A0=A0=A0=A0=A0=A0=A0=A0=A0 5.4 Gbps=A0=A0=A0=A0=A0=A0=A0=A0 5.5= Gbps > > 3=A0=A0=A0=A0=A0=A0=A0=A0=A0 5.2 Gbps=A0=A0=A0=A0=A0=A0=A0=A0 5.2= Gbps > > 4=A0=A0=A0=A0=A0=A0=A0=A0=A0 5.1 Gbps=A0=A0=A0=A0=A0=A0=A0=A0 5.0= Gbps > > 10=A0=A0=A0=A0=A0=A0=A0=A0 5.4 Gbps=A0=A0=A0=A0=A0=A0=A0=A0 5.2 G= bps > > 20=A0=A0=A0=A0=A0=A0=A0=A0 5.4 Gbps=A0=A0=A0=A0=A0=A0=A0=A0 5.4 G= bps > > > > > > ############ netperf TCP_RR ############# > > =A0=A0=A0=A0=A0=A0=A0 NO BATCHING=A0=A0=A0=A0=A0=A0=A0=A0 BATCHIN= G > > 1=A0=A0=A0=A0=A0=A0=A0=A0 13.0 Ktts=A0=A0=A0=A0=A0=A0=A0=A0 12.8 = Ktts > > 2=A0=A0=A0=A0=A0=A0=A0=A0 23.8 Ktts=A0=A0=A0=A0=A0=A0=A0=A0 23.0 = Ktts > > 3=A0=A0=A0=A0=A0=A0=A0=A0 34.0 Ktts=A0=A0=A0=A0=A0=A0=A0=A0 32.5 = Ktts > > 4=A0=A0=A0=A0=A0=A0=A0=A0 44.5 Ktts=A0=A0=A0=A0=A0=A0=A0=A0 41.0 = Ktts > > 10=A0=A0=A0=A0=A0=A0=A0 97.0 Ktts=A0=A0=A0=A0=A0=A0=A0=A0 93.0 Kt= ts > > 15=A0=A0=A0=A0=A0=A0 122.0 Ktts=A0=A0=A0=A0=A0=A0=A0 120.0 Ktts > > 20=A0=A0=A0=A0=A0=A0 125.0 Ktts=A0=A0=A0=A0=A0=A0=A0 128.0 Ktts > > 25=A0=A0=A0=A0=A0=A0 128.0 Ktts=A0=A0=A0=A0=A0=A0=A0 130.0 Ktts > > > > > > There is some negative effects introduced by batching. > > Also consider that > > =A0=A0 - Since TAP backend doesn't use the new flag, this patch d= oesn't > change the > > performance when the TAP backend is used. > > =A0=A0 - I've not submitted yet the patch for virtio_net_header s= upport, and > > therefore the TCP_STREAM performance with NETMAP backend is now n= ot > > =A0=A0=A0=A0 comparable to the performance with TAP backend, beca= use we are > limited to > > 1.5KB packets. > > > > Cheers, > > =A0 Vincenzo >=20 > 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. >=20 > 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. > =20 > -- > MST >=20 >=20 >=20 >=20 > -- > Vincenzo Maffione