Re: [PATCH RFC 2/3] Virtio draft III: example net driver

Avi Kivity
2007-06-25T22:20:06Z

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.