From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: TODO list for qemu+KVM networking performance v2 Date: Wed, 10 Jun 2009 17:53:58 +0300 Message-ID: <20090610145358.GB28601@redhat.com> References: <20090604164320.GB14592@redhat.com> <200906101309.14532.rusty@rustcorp.com.au> <4A2F5217.9090401@redhat.com> <200906110009.34671.rusty@rustcorp.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dlaor@redhat.com, virtualization@lists.linux-foundation.org, Chris Wright , Mark McLoughlin , kvm@vger.kernel.org, Brian Stein , Herbert Xu , Dor Laor , Avi Kivity , Yaron Haviv , Shahar Klein , Anthony Liguori To: Rusty Russell Return-path: Received: from mx2.redhat.com ([66.187.237.31]:53638 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755733AbZFJOzI (ORCPT ); Wed, 10 Jun 2009 10:55:08 -0400 Content-Disposition: inline In-Reply-To: <200906110009.34671.rusty@rustcorp.com.au> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jun 11, 2009 at 12:09:33AM +0930, Rusty Russell wrote: > On Wed, 10 Jun 2009 03:56:31 pm Dor Laor wrote: > > Rusty Russell wrote: > > > The current theoretical hole is that the host suppresses notifications > > > using the VIRTIO_AVAIL_F_NO_NOTIFY flag, but we can get a number of > > > notifications in before it gets to that suppression. You can use a > > > counter to improve this: you only notify when they're equal, and inc when > > > you notify. That way you suppress further notifications even if the > > > other side takes ages to wake up. In practice, this shouldn't be played > > > with until we have full aio (or equiv in kernel) for other side: host > > > xmit tends to be too fast at the moment and we get a notification per > > > packet anyway. > > > > Xen ring has the exact optimization for ages. imho we should have it > > too, regardless of aio. > > It reduces #vmexits/spurious wakeups and it is very simple to implement. > > But look at number of wakeups received vs notifications sent: I just don't see > any benefit there at the moment. As I said, improving the host code might > change that significantly. > > And implementing it the other way is v. v. hard given the nature of interrupts > (shared and coalesced). I agree it's not such a simple thing to implement race-free, so I do buy the argument that we shouldn't unless it gives a performance benefit. But I don't understand how aio will make implementing it easier - or are you merely saying that it will make it worthwhile? -- MST