All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Mark McLoughlin <markmc@redhat.com>
Cc: kvm@vger.kernel.org, Rusty Russell <rusty@rustcorp.com.au>,
	Herbert Xu <herbert.xu@redhat.com>,
	Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [PATCH 5/5] kvm: qemu: Improve virtio_net recv buffer	allocation scheme
Date: Tue, 14 Oct 2008 17:47:10 +0200	[thread overview]
Message-ID: <48F4BEFE.7090800@redhat.com> (raw)
In-Reply-To: <1223991840.11098.29.camel@blaa>

Mark McLoughlin wrote:
> Yeah, it's far from pretty. The current ABI basically says "you must
> supply >64k receive buffers" whereas this new ABI says "you must supply
> at least 18 >4k receive buffers".
>
> We could think about having the host expose the maximum rx packet size
> to the guest (and handle migrating to a host with a different max), but
> TBH I don't think it would be worth much until we have the prospect of
> running on a host with a larger maximum rx packet size.
>
> Requiring the guest to fill the ring with ~64k of buffers isn't onerous;
> the Linux guest impl currently re-fills the ring up to the max (e.g. 256
> x 4k)
>
>   

We should document the ABI somewhere.  All those hidden rules will make
implementing non-Linux drivers difficult, as well as maintaining
backwards compatibility.


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


  reply	other threads:[~2008-10-14 15:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-08 19:35 [PATCH 1/5] kvm: qemu: Move virtqueue_next_desc() around Mark McLoughlin
2008-10-08 19:35 ` [PATCH 2/5] kvm: qemu: Introduce virtqueue_fill() and virtqueue_flush() Mark McLoughlin
2008-10-08 19:35   ` [PATCH 3/5] kvm: qemu: Simplify virtio_net_can_receive() a little Mark McLoughlin
2008-10-08 19:35     ` [PATCH 4/5] kvm: qemu: Split iov_fill() out from virtio_net_receive() Mark McLoughlin
2008-10-08 19:35       ` [PATCH 5/5] kvm: qemu: Improve virtio_net recv buffer allocation scheme Mark McLoughlin
2008-10-12 10:00         ` Avi Kivity
2008-10-14 13:44           ` Mark McLoughlin
2008-10-14 15:47             ` Avi Kivity [this message]
2008-11-26 14:50             ` [PATCH 0/5] kvm: qemu: virtio_net: add support for mergeable rx buffers Mark McLoughlin
2008-11-26 14:50               ` [PATCH 1/5] kvm: qemu: virtio: move virtqueue_next_desc() around Mark McLoughlin
2008-11-26 14:50                 ` [PATCH 2/5] kvm: qemu: virtio: introduce virtqueue_fill() and virtqueue_flush() Mark McLoughlin
2008-11-26 14:50                   ` [PATCH 3/5] kvm: qemu: virtio: split some helpers out of virtqueue_pop() Mark McLoughlin
2008-11-26 14:50                     ` [PATCH 4/5] kvm: qemu: virtio-net: split iov_fill() out from virtio_net_receive() Mark McLoughlin
2008-11-26 14:50                       ` [PATCH 5/5] kvm: qemu: virtio-net: add a new virtio-net receive buffer scheme Mark McLoughlin
2008-11-27 12:45               ` [PATCH 0/5] kvm: qemu: virtio_net: add support for mergeable rx buffers Avi Kivity
2008-11-27 13:32                 ` Mark McLoughlin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48F4BEFE.7090800@redhat.com \
    --to=avi@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=herbert.xu@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=markmc@redhat.com \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.