WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Re: [kvm-devel] [PATCH RFC 1/3] virtio infrastructure

To: Avi Kivity <avi@xxxxxxxxxxxx>
Subject: [Xen-devel] Re: [kvm-devel] [PATCH RFC 1/3] virtio infrastructure
From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Date: Mon, 04 Jun 2007 21:19:24 +1000
Cc: Jimi Xenidis <jimix@xxxxxxxxxxxxxx>, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, "jmk@xxxxxxxxxxxxxxxxxxx" <jmk@xxxxxxxxxxxxxxxxxxx>, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, kvm-devel <kvm-devel@xxxxxxxxxxxxxxxxxxxxx>, virtualization <virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Christian Borntraeger <cborntra@xxxxxxxxxx>, Suzanne McIntosh <skranjac@xxxxxxxxxx>, Martin Schwidefsky <schwidefsky@xxxxxxxxxx>
Delivery-date: Mon, 04 Jun 2007 04:18:06 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4663E18D.4030007@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1180613947.11133.58.camel@xxxxxxxxxxxxxxxxxxxxx> <46610E8D.10706@xxxxxxxxxxxx> <1180777836.9228.44.camel@xxxxxxxxxxxxxxxxxxxxx> <46625192.5020108@xxxxxxxxxxxx> <1180866540.17442.74.camel@xxxxxxxxxxxxxxxxxxxxx> <4662A86A.7010706@xxxxxxxxxxxx> <1180914836.17442.104.camel@xxxxxxxxxxxxxxxxxxxxx> <4663E18D.4030007@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2007-06-04 at 12:55 +0300, Avi Kivity wrote:
> Rusty Russell wrote:
> > On Sun, 2007-06-03 at 14:39 +0300, Avi Kivity wrote:
> >   
> >> Rusty Russell wrote:
> >>     
> >>> Hmm... Perhaps I should move the used arrays into the "struct
> >>> virtio_device" and guarantee that the id (returned by add_*buf) is an
> >>> index into that.  Then we can trivially add a corresponding bit array. 
> >>>       
> >> That may force the virtio backend to do things it doesn't want to.
> >>     
> >
> > Well, I have two implementations, and both ids already fit this model so
> > I have some confidence.  I just need to add the set_bit/clear_bit to the
> > read/write one, and use sync_clear_bit to the descriptor-based one
> > (which I suspect will actually get a little cleaner).
> >
> > So I think this constraint is a reasonable thing to add anyway.
> 
> Some hardware (tulip IIRC, but long time ago) allows linked list based 
> descriptors.  If a virtio implementation takes a similar approach, it 
> may not have an array of descriptors.

Sure, but the mapping becomes non-trivial only if you have no ceiling on
the number in flight at any time.  OTOH, it's a very nice property for
driver authors.  I'll send the diffs once debugging is done...

> Networking hardware generally services descriptors in a FIFO manner.

Well, ethernet guarantees order.  Not sure about others tho...

> virtio may not (for example, it may offload copies of larger packets to 
> a dma engine such as I/OAT, resulting in a delay, but copy smaller 
> packets immediately).  that means that there will be some mismatch 
> between virtio drivers and real hardware drivers.

I think your point is that the completion bitmap (or indeed, the current
approach) does not maintain order?  Hmm, this is more convincing to me
than cache arguments, since some devices might want ordering and want
more than a single io in flight.

I shall ponder this more deeply...

Thanks!
Rusty.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel