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
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
