From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38745) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq1Kg-0007V4-UN for qemu-devel@nongnu.org; Mon, 09 Dec 2013 08:57:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vq1Ka-0007c2-UE for qemu-devel@nongnu.org; Mon, 09 Dec 2013 08:57:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:21627) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vq1Ka-0007bq-MJ for qemu-devel@nongnu.org; Mon, 09 Dec 2013 08:57:04 -0500 Date: Mon, 9 Dec 2013 16:00:29 +0200 From: "Michael S. Tsirkin" Message-ID: <20131209140029.GC15574@redhat.com> References: <1386341073-6584-1-git-send-email-v.maffione@gmail.com> <20131208121117.GD6841@redhat.com> <20131209103026.GC15055@redhat.com> <20131209111431.GG15055@redhat.com> <20131209124230.GC9611@stefanha-thinkpad.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 , Stefan Hajnoczi , Jason Wang , mjt@tls.msk.ru, qemu-devel@nongnu.org, lcapitulino@redhat.com, peter.crosthwaite@petalogix.com, owasserm@redhat.com, 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 , Dmitry Fleytman , mark.langsdorf@calxeda.com, Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= On Mon, Dec 09, 2013 at 02:25:46PM +0100, Vincenzo Maffione wrote: >=20 >=20 >=20 > 2013/12/9 Stefan Hajnoczi >=20 > On Mon, Dec 09, 2013 at 01:14:31PM +0200, Michael S. Tsirkin wrote: > > On Mon, Dec 09, 2013 at 11:55:57AM +0100, Vincenzo Maffione wrote= : > > > If you don't think adding the new flag support for virtio-net i= s a good > idea > > > (though TAP performance is not affected in every case) we could= also > make it > > > optional. > > > > > > > > > Cheers > > > =A0 Vincenzo > > > > > > > I think it's too early to say whether this patch is benefitial fo= r > > netmap, too. =A0It 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 conclusion= s about > it. >=20 > Just to check my understanding, we're talking about the following k= ind > of batching: >=20 > =A0 int num_packets =3D peek_available_packets(device); > =A0 while (num_packets-- > 0) { > =A0 =A0 =A0 int flags =3D MORE; > =A0 =A0 =A0 if (num_packets =3D=3D 0) { > =A0 =A0 =A0 =A0 =A0 flags =3D NONE; > =A0 =A0 =A0 } > =A0 =A0 =A0 qemu_net_send_packet(..., flags); > =A0 } >=20 > In other words, this only batches up a single burst of packets. =A0= It > doesn't introduce timers or blocking calls. >=20 > So the effect of batching should be relatively small on latency. =A0= In > fact, it's almost like sendmmsg(2)/recvmmsg(2) but using a > one-packet-at-a-time interface. >=20 > Does this sound right? > =20 > Stefan >=20 >=20 > Totally correct. >=20 > In reply to Michael: > =A0=A0 - what you say is right with netmap used as a backend with typic= al TCP > applications in the guests, and we have already an implementation that = supports > those offloadings >=20 > =A0=A0 - however, consider that the main use of netmap is fast packet p= rocessing in > middleboxes, where packet aggregation is not always possible. Applicati= ons that > use netmap **in the guest** typically use "packet batching" (i.e. send = multiple > packets with one system call), so batches originate in the guest. Witho= ut the > MORE flag, those batches are split at the frontend-backend interface. T= his is > just a different workload. >=20 >=20 > Regards, > -- > Vincenzo Maffione Considering that you have measured performance regression under netperf, I don't understand why do we keep arguing about theory. Increasing latency is a problem and if it can already be seen with netperf it will only get worse with real life workloads. So my advice is, start by merging offload support for netmap, then check whether this optimization adds enough performance to be worth it, if yes it needs more heuristics to avoid hurting latency. --=20 MST