qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Anton Kuchin <antonkuchin@yandex-team.ru>, qemu-devel@nongnu.org
Cc: mst@redhat.com
Subject: Re: [Qemu-devel] Is IOThread for virtio-net a good idea?
Date: Tue, 12 Feb 2019 14:48:22 +0800	[thread overview]
Message-ID: <078dfb4d-2467-6a2c-1964-a463839e8183@redhat.com> (raw)
In-Reply-To: <e6c30bdd-6cd0-ee9b-9fdf-cc8eaa54f7cc@yandex-team.ru>


On 2019/2/11 下午9:40, 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?
>

I think there're no obstacles.

The only question is whether or not you need to support legacy 
networking backends. If the answer is yes, you need to convert them not 
to assume context of Main Loop. But I don't think it's worth to support 
them. We should focus on high speed solution like linking dpdk.

Another issue is the virtio implementation. Dpdk has virtio library 
which is pretty optimized, we should consider to use it. But last time I 
check the code, it was tightly coupled with AF_UNIX transport of 
vhost-user. We may want to decouple it out of dpdk. Of course we can do 
it our own as well. (Yes I know there's a vhost-user implementation, but 
it was not optimized for performance).

I do have some prototype that is based on vhost-scsi-dataplane with a 
TAP backend. I can send it to you if you wish.

Thanks

  parent reply	other threads:[~2019-02-12  6:48 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
2019-02-12  6:59     ` Jason Wang
2019-02-12  6:41   ` Jason Wang
2019-02-12  6:48 ` Jason Wang [this message]
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=078dfb4d-2467-6a2c-1964-a463839e8183@redhat.com \
    --to=jasowang@redhat.com \
    --cc=antonkuchin@yandex-team.ru \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.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).