Re: [Qemu-devel] [PATCH 14/15] hw/block/virtio-blk: create num_queues vqs if dataplane is enabled

[Ming Lei <ming.lei@canonical.com>]

On Wed, Jul 30, 2014 at 11:25 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> Il 30/07/2014 17:12, Michael S. Tsirkin ha scritto:
>>> >
>>> > Dataplane must not be a change to the guest ABI.  If you implement this
>>> > feature you have to implement it for both dataplane and non-dataplne.
>>> >

IMO, no matter if the feature is set or not, both old and new VM
can support it well.

Per virtio spec, only the feature is set, the VM can be allowed to
access the 'num_queues' field, and I didn't see any problem from
VM's view point.

So could you explain why both dataplane and non-dataplane have
to support the feature.

I am doing so because there isn't performance advantage to take mq
for non-dataplane.

>>> > Paolo
>> Actually, I think different backends at runtime should be allowed to
>> change guest visible ABI.  For example if you give qemu a read only
>> backend this is guest visible right?
>
> Dataplane is not meant to be a different backend, it's just moving stuff
> out to a separate thread.  It's only due to QEMU limitation that it
> doesn't share the vring code (and these patches include a lot of steps
> backwards where dataplane becomes != non-dataplane).

There won't lots of backwards steps, just the bypass co patch, which
is just bypassing co in case of being unnecessary for raw image case,
but it is still one code path.

As I mentioned, all these steps are just for the performance
regression from the commit 580b6b2aa2(dataplane: use the
QEMU block layer for I/O).

Thanks,