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: [kvm-devel] [PATCH RFC 2/3] Virtio draft III: example ne

To: brking@xxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Re: [kvm-devel] [PATCH RFC 2/3] Virtio draft III: example net driver
From: Avi Kivity <avi@xxxxxxxxxxxx>
Date: Mon, 25 Jun 2007 18:20:06 -0400
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>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Christian Borntraeger <cborntra@xxxxxxxxxx>, Latchesar Ionkov <lionkov@xxxxxxxx>, Suzanne McIntosh <skranjac@xxxxxxxxxx>, Martin Schwidefsky <schwidefsky@xxxxxxxxxx>
Delivery-date: Mon, 25 Jun 2007 15:17:21 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <46803E0E.7080103@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> <20070625193304.GB25736@xxxxxxxxxxxxx> <46803999.4040500@xxxxxxxxxxxx> <46803E0E.7080103@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.4 (X11/20070615)
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