WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: brking@xxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Re: [PATCH RFC 2/3] Virtio draft III: example net driver
From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Date: Thu, 28 Jun 2007 21:20:40 +1000
Cc: Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx>, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxx>, "jmk@xxxxxxxxxxxxxxxxxxx" <jmk@xxxxxxxxxxxxxxxxxxx>, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, kvm-devel <kvm-devel@xxxxxxxxxxxxxxxxxxxxx>, virtualization <virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx>, Christian Borntraeger <cborntra@xxxxxxxxxx>, Latchesar Ionkov <lionkov@xxxxxxxx>, Suzanne McIntosh <skranjac@xxxxxxxxxx>, Martin Schwidefsky <schwidefsky@xxxxxxxxxx>
Delivery-date: Thu, 28 Jun 2007 04:19:06 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <467FDEAD.4030204@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1181217762.14054.192.camel@xxxxxxxxxxxxxxxxxxxxx> <1181999552.6237.255.camel@xxxxxxxxxxxxxxxxxxxxx> <1181999669.6237.257.camel@xxxxxxxxxxxxxxxxxxxxx> <1181999825.6237.260.camel@xxxxxxxxxxxxxxxxxxxxx> <467FDEAD.4030204@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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