| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] Re: [PATCH RFC 2/3] Virtio draft III: example net driver
|
To: |
Rusty Russell <rusty@xxxxxxxxxxxxxxx> |
|
Subject: |
[Xen-devel] Re: [PATCH RFC 2/3] Virtio draft III: example net driver |
|
From: |
Brian King <brking@xxxxxxxxxxxxxxxxxx> |
|
Date: |
Thu, 28 Jun 2007 10:55:59 -0500 |
|
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: |
Fri, 29 Jun 2007 08:41:32 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<1183029641.12401.36.camel@xxxxxxxxxxxxxxxxxxxxx> |
|
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> <1183029641.12401.36.camel@xxxxxxxxxxxxxxxxxxxxx> |
|
Reply-to: |
brking@xxxxxxxxxxxxxxxxxx |
|
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
|
User-agent: |
Thunderbird 1.5.0.12 (X11/20060911) |
Rusty Russell wrote:
> 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?
The current maximum supported MTU for ibmveth is 64k. Additionally,
the firmware interface for ibmveth allows for multiple rx "pools" of
different sizes to be allocated and given to the hypervisor. Depending
on the incoming packet size, the smallest buffer is then chosen. Just
something to keep in mind as you look at adding large frame support. I'm
not sure what requirements other users would have...
> 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...
memmove definitely does not sound optimal. I would definitely prefer returning
an offset on get_buf, but when I get something up and running I could
certainly run some benchmarks.
> 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...
I've started working on some code, but only to get a better handle on the API
and see what issues ibmveth might run into. I was expecting some code churn
yet at this stage..
-Brian
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home