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. > 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, 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, bypassing coroutines for dataplane only is a backwards step. Paolo
