From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MadF6-0005mM-St for qemu-devel@nongnu.org; Mon, 10 Aug 2009 18:21:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MadF2-0005m2-49 for qemu-devel@nongnu.org; Mon, 10 Aug 2009 18:21:24 -0400 Received: from [199.232.76.173] (port=50028 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MadF2-0005lz-1T for qemu-devel@nongnu.org; Mon, 10 Aug 2009 18:21:20 -0400 Received: from mx20.gnu.org ([199.232.41.8]:17446) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MadF0-0002Dj-U4 for qemu-devel@nongnu.org; Mon, 10 Aug 2009 18:21:19 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MadEs-0004bQ-R9 for qemu-devel@nongnu.org; Mon, 10 Aug 2009 18:21:11 -0400 Date: Tue, 11 Aug 2009 01:19:40 +0300 From: "Michael S. Tsirkin" Subject: Re: [Qemu-devel] Re: [PATCH] qemu/virtio: move features to an inline function Message-ID: <20090810221940.GB17099@redhat.com> References: <20090810192809.GA16800@redhat.com> <4A8076F0.5050700@codemonkey.ws> <20090810194753.GA16803@redhat.com> <4A808437.8040307@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A808437.8040307@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: rusty@rustcorp.com.au, qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org On Mon, Aug 10, 2009 at 03:33:59PM -0500, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >>> Normally, the common features are transport features and the devices >>> should have absolutely no knowledge of transport feature (since >>> they're transport dependent). >>> >> >> Good point. But >> >> 1. note that with my patch they don't. They call >> virtio_get_common_features and that's all. >> >> 2. some features may not make sense for some devices. For example, it is >> quite possible that indirect ring entries feature improves performance >> on block but hurts on net, as net has a similar merged buffers feature. >> Someone should try benchmarking with it disabled, and it becomes >> possible with my patch. >> > > I don't necessarily disagree but I think your patch goes about it the > wrong way. > > There ought to be a way to layer qdev properties that achieves this goal > so that when you create a virtio-pci-block device, you have the ability > to turn off indirect sg without virtio-block having to know what that is. I don't understand, sorry. Why do you insist on involving pci here? ring layout has nothing to do with pci, does it? With my patch, virtio-block does not know what indirect sg is. It just does enable/disable. virtio net has device-specific feature that overlaps with indirect entries. So insisting that devices should just ignore transport does not make sense, to me. > For your use-case, I wonder if you're integrating at the wrong level. Forget about that for now. Let's solve the generic problem. > Regards, > > Anthony Liguori