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

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

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


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/