From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:40026)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1TgqlQ-0007It-KI
	for qemu-devel@nongnu.org; Fri, 07 Dec 2012 00:46:22 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1TgqlN-0004tP-Pu
	for qemu-devel@nongnu.org; Fri, 07 Dec 2012 00:46:20 -0500
Received: from mx1.redhat.com ([209.132.183.28]:39727)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@redhat.com>) id 1TgqlN-0004tJ-JO
	for qemu-devel@nongnu.org; Fri, 07 Dec 2012 00:46:17 -0500
Date: Fri, 7 Dec 2012 06:46:14 +0100
From: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20121207054614.GD4973@stefanha-thinkpad.redhat.com>
References: <1354740430-22452-1-git-send-email-stefanha@redhat.com>
	<50C157CC.1000405@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <50C157CC.1000405@gmail.com>
Subject: Re: [Qemu-devel] [PATCH v5 00/11] virtio: virtio-blk data plane
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Liu Yuan <namei.unix@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, "Michael S. Tsirkin" <mst@redhat.com>, qemu-devel@nongnu.org, Blue Swirl <blauwirbel@gmail.com>, khoa@us.ibm.com, Paolo Bonzini <pbonzini@redhat.com>, asias@redhat.com

On Fri, Dec 07, 2012 at 10:43:24AM +0800, Liu Yuan wrote:
> On 12/06/2012 04:46 AM, Stefan Hajnoczi wrote:
> > Limitations:
> >  * Only format=raw is supported
> 
> The boost number looks promising, but support of other format(which
> might as well fit into this new IO path design) is in the plan? It seems
> that bypassing block layer would end up adding yet another 'block layer'
> as we add more format support.

Right, that's why the next step is to complete the AioContext work that
Paolo recently contributed.  It will allow us to run the QEMU block
layer outside the global mutex.

Once that refactoring is complete the data plane thread will be able to
run image format code.

We'll need to be careful so as not to lose the level of performance that
it achieves right now, but there is no fundamental reason why we cannot
continue to keep this level of performance while still supporting image
formats.

Stefan