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

[Avi Kivity <avi@xxxxxxxxxxxx>]

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.

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