From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHXmM-0002JZ-SV for qemu-devel@nongnu.org; Wed, 13 Aug 2014 08:35:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XHXmD-000175-OO for qemu-devel@nongnu.org; Wed, 13 Aug 2014 08:35:46 -0400 Received: from mail-wg0-x22a.google.com ([2a00:1450:400c:c00::22a]:33111) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHXmD-000171-Ef for qemu-devel@nongnu.org; Wed, 13 Aug 2014 08:35:37 -0400 Received: by mail-wg0-f42.google.com with SMTP id l18so11033205wgh.13 for ; Wed, 13 Aug 2014 05:35:36 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <53EB5B84.20503@redhat.com> Date: Wed, 13 Aug 2014 14:35:16 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1407209598-2572-1-git-send-email-ming.lei@canonical.com> <20140805094844.GF4391@noname.str.redhat.com> <20140805134815.GD12251@stefanha-thinkpad.redhat.com> <20140805144728.GH4391@noname.str.redhat.com> <20140806084855.GA4090@noname.str.redhat.com> <20140810114624.0305b7af@tom-ThinkPad-T410> <53E91B5D.4090009@redhat.com> <53EA6635.9040600@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v1 00/17] dataplane: optimization and multi virtqueue support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ming Lei Cc: Kevin Wolf , Fam Zheng , qemu-devel , Stefan Hajnoczi Il 13/08/2014 12:19, Ming Lei ha scritto: >> > The problem is that your patches to do touch too much code and subtly >> > break too much stuff. The one I wrote does have a little breakage > Could you give a hint about which stuff are broken? Last time, you mention > virtio-scsi need to keep AIOCB live after returning, I have fixed it in V1. They are dataplane-specific, while there's no reason not to have the same benefits elsewhere. They are file-specific, while there's no reason not to have the same benefits for e.g. iSCSI (though iSCSI now uses coroutines instead of bdrv_aio_*). They touch AioContext for no reason, and introduce a bunch of layering violations everywhere. They are simply the wrong API. >> > because I don't understand bs->growable 100% and I didn't really put >> > much effort into it (my deadline being basically "be done as soon as the >> > shower is free"), and it is ugly as hell, _but_ it should be compatible >> > with the way the block layer works. > I will take a careful look to your patch later. > > If coroutine is still there, I think it still can slow down performance. No, it's not there. Please try the patch. Paolo