Re: [kvm-devel] [Xen-devel] Re: [PATCH RFC 1/3] virtio infrastructure
On Mon, Jun 04, 2007 at 12:55:25PM +0300, Avi Kivity wrote:
>
> 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.
You're free to do that in the process but before your packets leave
the backend you've got to make sure that they haven't been reordered.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Xen-devel] Re: [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 - 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/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Xen-devel] Re: [PATCH RFC 1/3] virtio infrastructure
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.
> > This also makes the "id" easier to use from the driver side: if we add a
> > "max_id" field it can size its own arrays if it wants to. Gets rid of
> > the linked-list in the block driver...
> >
>
> How about
>
> struct virtio_completion {
> unsigned long length;
> void *data;
> };
>
> int virtio_complete(struct virtio_completion *completions, int nr);
>
> where 'data' is an opaque pointer passed by the device during add_*buf()?
Other than the fact that the driver will look less like a normal driver,
it's actually harder to write the net driver if that complete call can
happen off an interrupt: we can't free skbs in interrupt context, which
is why the used-outbuf cleanup is currently done (inefficiently, but
that's orthogonal) in the xmit routine.
I'll code up the modifications now and check if I'm right about the
impact on the code. I might have to come up with something else...
Cheers,
Rusty.
-
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/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Xen-devel] Re: [PATCH RFC 1/3] virtio infrastructure
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.
> This also makes the "id" easier to use from the driver side: if we add a
> "max_id" field it can size its own arrays if it wants to. Gets rid of
> the linked-list in the block driver...
>
How about
struct virtio_completion {
unsigned long length;
void *data;
};
int virtio_complete(struct virtio_completion *completions, int nr);
where 'data' is an opaque pointer passed by the device during add_*buf()?
--
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/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
