On Thu, Jul 31, 2014 at 4:52 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > Il 31/07/2014 05:47, Ming Lei ha scritto: >> On Wed, Jul 30, 2014 at 11:25 PM, Paolo Bonzini <pbonz...@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. > > 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,
