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

[Avi Kivity <avi@xxxxxxxxxxxx>]

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.
Networking hardware generally services descriptors in a FIFO manner.  
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.
For block devices, reordering is a matter of course, and virtio needs to 
efficiently support that.  Queues are generally shorter for block, though.
--
error compiling committee.c: too many arguments to function


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