| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [kvm-devel] [PATCH RFC 1/3] virtio infrastructure
|
To: |
Rusty Russell <rusty@xxxxxxxxxxxxxxx> |
|
Subject: |
Re: [Xen-devel] Re: [kvm-devel] [PATCH RFC 1/3] virtio infrastructure |
|
From: |
Avi Kivity <avi@xxxxxxxxxxxx> |
|
Date: |
Mon, 04 Jun 2007 12:55:25 +0300 |
|
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 02:53:38 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<1180914836.17442.104.camel@xxxxxxxxxxxxxxxxxxxxx> |
|
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> |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Thunderbird 2.0.0.0 (X11/20070419) |
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
|
|
|
| |
|
Home