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

[Ming Lei]

On Thu, Jul 31, 2014 at 4:52 PM, Paolo Bonzini <address@hidden> wrote:
> Il 31/07/2014 05:47, Ming Lei ha scritto:
>> On Wed, Jul 30, 2014 at 11:25 PM, Paolo Bonzini <address@hidden> 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.
>
> Because otherwise you change the guest ABI.

Sorry, I don't understand why the guest ABI is changed since
VM only parses 'num_queues' iff the feature is set, and the DATAPLANE
macro is determined during compiling.

>
>> I am doing so because there isn't performance advantage to take mq
>> for non-dataplane.
>
> It doesn't matter, changing features between dataplane and non-dataplane
> is not something that you can do.

Actually it is easy to support multi virtqueue for non-dataplane,
and it should be enough to remove two 'ifdef'.

>
>>>> 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.
>
> Using the object pool for dataplane only is a backwards step,
> implementing multique for dataplane only is a backwards step,

This one isn't since no multique has been tried before for virtio-blk, :-)

> bypassing
> coroutines for dataplane only is a backwards step.

OK, then all these backwards are positive steps too since they
do improve performance, :-)

The only side-effect I thought of is that bypassing coroutine may
cause block layer a bit complicated.

Thanks,