26 messages in com.xensource.lists.xen-devel[Xen-devel] Re: [kvm-devel] [PATCH RF...
FromSent OnAttachments
Rusty Russell07 Jun 2007 05:02 
Rusty Russell07 Jun 2007 05:04 
Rusty Russell07 Jun 2007 05:04 
Rusty Russell07 Jun 2007 05:06 
Avi Kivity07 Jun 2007 05:18 
Rusty Russell07 Jun 2007 18:11 
Rusty Russell16 Jun 2007 06:12 
Rusty Russell16 Jun 2007 06:14 
Rusty Russell16 Jun 2007 06:16 
Rusty Russell16 Jun 2007 06:18 
Rusty Russell16 Jun 2007 06:28 
Arnd Bergmann16 Jun 2007 06:50 
Avi Kivity17 Jun 2007 07:14 
Avi Kivity17 Jun 2007 07:24 
Rusty Russell18 Jun 2007 00:47 
Rusty Russell18 Jun 2007 01:07 
Avi Kivity18 Jun 2007 02:08 
Rusty Russell18 Jun 2007 23:27 
Avi Kivity19 Jun 2007 01:34 
Brian King25 Jun 2007 08:26 
Christoph Hellwig25 Jun 2007 12:32 
Avi Kivity25 Jun 2007 14:54 
Brian King25 Jun 2007 15:13 
Avi Kivity25 Jun 2007 15:19 
Rusty Russell28 Jun 2007 04:20 
Brian King28 Jun 2007 08:55 
Subject:[Xen-devel] Re: [kvm-devel] [PATCH RFC 2/3] Virtio draft III: example net driver
From:Avi Kivity (av@qumranet.com)
Date:06/25/2007 03:19:43 PM
List:com.xensource.lists.xen-devel

Brian King wrote:

I'm probably missing something. What is wrong with a scatterlist of length 1?

Absolutely nothing, as long as the interface guarantees I don't see a larger scatterlist. With the current implementation it looks to me like this is always true, but if we were to stick to using a scatterlist, it would make sense to allow the user to specify a max sg length supported. This value could be different for in vs. out buffers.

Okay; so virtio net should have configurable scatterlist max sizes.

2. The user of this API does not have access to the sk_buf. This causes issues for ibmveth since it needs to reserve the first 8 bytes of the rx buffer for use by the firmware. It currently uses skb_reserve to do this.

Would it be simpler to just pass an sk_buf rather than the scatterlist on these interfaces for virtio_net users?

It probably should pass the sk_buff.

But virtio is a generic layer that is useful for more than just networking.

Agreed. However, this one is a huge issue for ibmveth. ibmveth must write a tag to the first 8 bytes of each rx buffer before passing the buffer to the pSeries hypervisor. The hypervisor then writes this tag to the rx queue when the buffer is used. This first 8 bytes of the rx buffer is not overlayed with data.
Additionally, the hypervisor may offset further than 8 bytes into the buffer for the start of the payload if it so desires. The offset is also written to the rx queue.

Another option which would solve this problem would be if the get_inbuf interface also returned an offset into the original data buffer where the payload starts.

I guess. Rusty was concerned that virtio will explode to the sum of all options on all hypervisors, and we now see it begin.