From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32888) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCm69-0008DH-Q9 for qemu-devel@nongnu.org; Thu, 31 Jul 2014 04:52:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XCm60-0000aG-LB for qemu-devel@nongnu.org; Thu, 31 Jul 2014 04:52:29 -0400 Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]:59156) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XCm60-0000aA-Dk for qemu-devel@nongnu.org; Thu, 31 Jul 2014 04:52:20 -0400 Received: by mail-wi0-f169.google.com with SMTP id n3so903614wiv.2 for ; Thu, 31 Jul 2014 01:52:19 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <53DA03BF.7030809@redhat.com> Date: Thu, 31 Jul 2014 10:52:15 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1406720388-18671-1-git-send-email-ming.lei@canonical.com> <1406720388-18671-15-git-send-email-ming.lei@canonical.com> <53D8FAD7.1070509@redhat.com> <20140730151232.GC26313@redhat.com> <53D90E4C.3090105@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 14/15] hw/block/virtio-blk: create num_queues vqs if dataplane is enabled List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ming Lei Cc: Kevin Wolf , Peter Maydell , Fam Zheng , "Michael S. Tsirkin" , qemu-devel , Stefan Hajnoczi Il 31/07/2014 05:47, Ming Lei ha scritto: > On Wed, Jul 30, 2014 at 11:25 PM, Paolo Bonzini 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