From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37073) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRsT0-0001qu-N7 for qemu-devel@nongnu.org; Wed, 01 Jun 2011 16:56:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRsSz-0007HN-Fa for qemu-devel@nongnu.org; Wed, 01 Jun 2011 16:56:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRosl-00057p-0l for qemu-devel@nongnu.org; Wed, 01 Jun 2011 13:06:59 -0400 Message-ID: <4DE668D5.7050600@redhat.com> Date: Wed, 01 Jun 2011 19:29:09 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4DD6246F.4080802@gnu.org> <4DE642CC.8000906@redhat.com> <4DE667DE.702@redhat.com> In-Reply-To: <4DE667DE.702@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] virtio scsi host draft specification, v2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Paolo Bonzini , qemu-devel , Stefan Hajnoczi On 06/01/2011 07:25 PM, Paolo Bonzini wrote: > On 06/01/2011 03:46 PM, Avi Kivity wrote: >> >>> Virtqueues >>> 0:control transmitq >>> 1:control receiveq >>> 2:requestq >>> >> >> Shouldn't we plan multiqueue for this from day 1? > > How would you do multiqueue? Just provide N queues, and the device > can place requests for any LUN on any queue? Yes. > If that's correct, it doesn't sound too hard to do, but also doesn't > sound problematic to fit it later. So I'm quite ambivalent Since it's easy, why not? Reducing feature bit proliferation means easier testing. >> >> flags? room for growth? > > Feature bits can be used to negotiate the exact format of the request. > I don't expect many changes, since we're closely mimicking the SCSI > requests. Ok. If we're following a standard we should be safe. -- error compiling committee.c: too many arguments to function