From: "Michael S. Tsirkin" <mst@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: kvm <kvm@vger.kernel.org>, qemu-devel <qemu-devel@nongnu.org>,
Linux Virtualization <virtualization@lists.linux-foundation.org>,
herbert@gondor.hengli.com.au, netdev@vger.kernel.org
Subject: Re: updated: kvm networking todo wiki
Date: Thu, 30 May 2013 16:44:49 +0300 [thread overview]
Message-ID: <20130530134449.GA31649@redhat.com> (raw)
In-Reply-To: <87k3mg60ww.fsf@codemonkey.ws>
On Thu, May 30, 2013 at 08:40:47AM -0500, Anthony Liguori wrote:
> Stefan Hajnoczi <stefanha@gmail.com> writes:
>
> > On Thu, May 30, 2013 at 7:23 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> >> Anthony Liguori <anthony@codemonkey.ws> writes:
> >>> Rusty Russell <rusty@rustcorp.com.au> writes:
> >>>> On Fri, May 24, 2013 at 08:47:58AM -0500, Anthony Liguori wrote:
> >>>>> FWIW, I think what's more interesting is using vhost-net as a networking
> >>>>> backend with virtio-net in QEMU being what's guest facing.
> >>>>>
> >>>>> In theory, this gives you the best of both worlds: QEMU acts as a first
> >>>>> line of defense against a malicious guest while still getting the
> >>>>> performance advantages of vhost-net (zero-copy).
> >>>>>
> >>>> It would be an interesting idea if we didn't already have the vhost
> >>>> model where we don't need the userspace bounce.
> >>>
> >>> The model is very interesting for QEMU because then we can use vhost as
> >>> a backend for other types of network adapters (like vmxnet3 or even
> >>> e1000).
> >>>
> >>> It also helps for things like fault tolerance where we need to be able
> >>> to control packet flow within QEMU.
> >>
> >> (CC's reduced, context added, Dmitry Fleytman added for vmxnet3 thoughts).
> >>
> >> Then I'm really confused as to what this would look like. A zero copy
> >> sendmsg? We should be able to implement that today.
> >>
> >> On the receive side, what can we do better than readv? If we need to
> >> return to userspace to tell the guest that we've got a new packet, we
> >> don't win on latency. We might reduce syscall overhead with a
> >> multi-dimensional readv to read multiple packets at once?
> >
> > Sounds like recvmmsg(2).
>
> Could we map this to mergable rx buffers though?
>
> Regards,
>
> Anthony Liguori
Yes because we don't have to complete buffers in order.
> >
> > Stefan
next prev parent reply other threads:[~2013-05-30 13:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-23 8:50 updated: kvm networking todo wiki Michael S. Tsirkin
2013-05-23 14:12 ` Lucas Meneghel Rodrigues
2013-05-24 9:41 ` Jason Wang
2013-05-24 11:35 ` Michael S. Tsirkin
2013-05-24 13:47 ` Anthony Liguori
2013-05-24 14:00 ` Michael S. Tsirkin
2013-05-29 0:07 ` Rusty Russell
2013-05-29 13:01 ` Anthony Liguori
2013-05-29 14:12 ` Michael S. Tsirkin
2013-05-30 5:23 ` Rusty Russell
2013-05-30 6:38 ` Stefan Hajnoczi
2013-05-30 7:18 ` Rusty Russell
2013-05-30 13:40 ` Anthony Liguori
2013-05-30 13:44 ` Michael S. Tsirkin [this message]
2013-05-30 14:41 ` Anthony Liguori
2013-06-03 0:32 ` Rusty Russell
2013-05-30 13:39 ` Anthony Liguori
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=20130530134449.GA31649@redhat.com \
--to=mst@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=herbert@gondor.hengli.com.au \
--cc=kvm@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=qemu-devel@nongnu.org \
--cc=virtualization@lists.linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).