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

[Rusty Russell <rusty@xxxxxxxxxxxxxxx>]

On Mon, 2007-06-25 at 10:26 -0500, Brian King wrote: 
> I've started to look at these patches to figure out how easily I
> could convert the ibmveth driver to use this new infrastructure
> and have ran into a few issues. So far the two biggest issues I've
> encountered are:

Hi Brian,

        Thanks for looking at this!  Sorry for the slow reply, I've been
travelling.

> 1. The add_inbuf interface passes an sg list. This causes problems for
>    ibmveth since its rx buffers cannot be scatterlists.
> 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 would be easier, but not suitable for block and other devices which
use the same interface.  Fortunately, I think there are solutions to
your issues.

1. 1500 byte packets will always be 1 sg long (ie. you should BUG_ON()
if that ever happens).  The issue is MTU > PAGE_SIZE, where I was
planning to allocate discontig pages.  I can't quite see what your
maximum supported MTU is, though?

2. The header problem is difficult (I can't resist pointing out that if
you had sg receive capability, it would be trivial 8).  The two
possibilities are to have get_buf take a "unsigned long *off" as well,
or to have ibm_veth do a memmove.

memmove sounds horrible at first glance, but since the hypervisor has
just copied the packet I'm not sure we'll notice in practice.
Benchmarking should tell...

BTW, after Avi's comments I have a new virtio draft, but still debugging
my implementation.  It doesn't effect this discussion, but would involve
churn for an actual implementation if you've gotten that far...

Thanks,
Rusty.


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