netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).