[Xen-devel] Re: [kvm-devel] [PATCH RFC 2/3] Virtio draft III: example net driver

[Brian King <brking@xxxxxxxxxxxxxxxxxx>]

Avi Kivity wrote:
> Christoph Hellwig wrote:
>> On Mon, Jun 25, 2007 at 10:26:37AM -0500, Brian King wrote:
>>   
>>> 1. The add_inbuf interface passes an sg list. This causes problems for
>>>    ibmveth since its rx buffers cannot be scatterlists.
>>>     
> 
> 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.

>>> 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.

-Brian

-- 
Brian King
Linux on Power Virtualization
IBM Linux Technology Center

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel