qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Anton Kuchin <antonkuchin@yandex-team.ru>,
	jasowang@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Is IOThread for virtio-net a good idea?
Date: Mon, 11 Feb 2019 23:35:35 -0500	[thread overview]
Message-ID: <20190211233246-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20190212035505.GE28401@stefanha-x1.localdomain>

On Tue, Feb 12, 2019 at 11:55:05AM +0800, Stefan Hajnoczi wrote:
> On Mon, Feb 11, 2019 at 09:52:01AM -0500, Michael S. Tsirkin wrote:
> > On Mon, Feb 11, 2019 at 04:40:44PM +0300, Anton Kuchin wrote:
> > > As far as I can see currently IOThread offloading is used only for block
> > > devices and all others are emulated by main thread.
> > > 
> > > I expect that network devices can also benefit from processing in separate
> > > thread but I couldn't find any recent work in this direction. I'm going to
> > > implement a PoC but I want to ask if you know any previous attempts and do
> > > you know why it can be a total waste of time. Are there fundamental
> > > obstacles that prevent network emulation handling in IOThread?
> > 
> > No but vhost-net is there. Unlike block where you gain lots of
> > functionality such as snapshots there seems to be little to
> > be gained by doing it in userspace.
> 
> Anthony Liguori tried virtio-net in a dedicated thread a long time ago
> but it was never completed/merged.
> 
> I think the argument for vhost-net in the kernel is that userspace
> doesn't offer the same APIs as the kernel.  For example, is zero copy
> possible from userspace?

Esp with recent spectre/meltdown mitigations, with vhost we are looking
for new ways to batch access checks and avoid overhead.

If you are going to pass the packets back to kernel, you
are better off with them never leaving the kernel.

> Anton: If you want to do virtio-net in userspace, QEMU has
> vhost-user-net support so you can perform emulation in a separate
> process.
> 
> Stefan

And the main point of that is to use a userspace
driver for a hardware nic so packets never end up in kernel.

  reply	other threads:[~2019-02-12  4:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-11 13:40 [Qemu-devel] Is IOThread for virtio-net a good idea? Anton Kuchin
2019-02-11 14:52 ` Michael S. Tsirkin
2019-02-12  3:55   ` Stefan Hajnoczi
2019-02-12  4:35     ` Michael S. Tsirkin [this message]
2019-02-12  6:59     ` Jason Wang
2019-02-12  6:41   ` Jason Wang
2019-02-12  6:48 ` Jason Wang
2019-02-12  7:00   ` Jason Wang
2019-02-12 18:40     ` Michael S. Tsirkin
2019-02-13  9:38       ` Jason Wang

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=20190211233246-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=antonkuchin@yandex-team.ru \
    --cc=jasowang@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    /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).