[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-devel] Re: [kvm-devel] [PATCH RFC 2/3] Virtio draft III: example net driver
- To: brking@xxxxxxxxxxxxxxxxxx
- 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
- List-id: Xen developer discussion <xen-devel.lists.xensource.com>
Brian King wrote:
I'm probably missing something. What is wrong with a scatterlist of
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.
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
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