[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.