Re: [Qemu-devel] Some thoughts about per-queue iothreads in VirtIOBlock

[Edgar Kaziakhmedov]

On 4/3/18 3:27 PM, Stefan Hajnoczi wrote:
> On Tue, Mar 20, 2018 at 07:30:04PM +0300, Edgar Kaziakhmedov wrote:
> > On 3/20/18 6:34 PM, Paolo Bonzini wrote:
> > > On 20/03/2018 15:45, Edgar Kaziakhmedov wrote:
> > >
> > > > As I understood from
> > > > Stefan description, it is expected to change significantly
> > > > the approach we use to interact with BlockDriverState.
> > > I don't think the change is very large actually, at least for on-disk
> > > devices.  I haven't yet considered network devices such as libiscsi or ceph.
> > Well, in that case, I will keep working on per-queue iothreads with an
> > existing interface.
> > I asked because it might be reasonable to create BlockBackend device for
> > each queue context and
> > use them independently to avoid some additional locks and synchronization.
> > On the other hand, it can lead to multiple
> > opening of the same image, but as I said it doesn't seem to be a problem for
> > the simplest formats such as raw.
> The special case for raw approach is not suitable for upstream QEMU.
> It's what we started with in -device virtio-blk,x-data-plane=on (see the
> old dataplane implementation in QEMU v1.4).


Yes, definitely. I went through the whole development path and analyzed 
all your patches. Moreover,
it is clear that this approach is not suitable for the upstream, but I 
am considering it like the first step toward
per-queue iothread implementation, for now the work seems to be almost 
done, may be it might take one more week to
refine and debug.

> It took a lot of work to make the IOThread use the QEMU block layer
> instead of a special case code path for raw.
>
> Currently QEMU is not that far away from being able to use
> BlockDriverState from multiple threads for multiqueue.
>
> Paolo, can you share your current progress and pointers to what needs to
> be done next?  Maybe Edgar can help complete the work.
>
> Stefan