From: Jason Wang <jasowang@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
Anton Kuchin <antonkuchin@yandex-team.ru>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Is IOThread for virtio-net a good idea?
Date: Tue, 12 Feb 2019 14:41:51 +0800 [thread overview]
Message-ID: <b775d7dc-4def-6d7c-ebff-d0b18169c52b@redhat.com> (raw)
In-Reply-To: <20190211095049-mutt-send-email-mst@kernel.org>
On 2019/2/11 下午10:52, 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.
I think all the three (vhost-net, vhost-user, vhost-dataplane) have
their own advantages. E.g compared to vhost-user, vhost dataplane in
qemu has the following advantages:
- Qemu dataplane could be much safer, e.g there's no need to share all
its memory to another process.
- Easy to develop, there's no need for the backend to know anything
about virtio. This will reduce the pain of maintaining compatibility,
version etc. New features was limited to the changes of qemu itself.
- Faster access of VM metadata, Device IOTLB and RSS/Steering could be
function calls instead of complex vhost-user protocol. I'm pretty sure
we will hit more similar issues in the future.
And I can consider some use cases:
- link dpdk to qemu
- implement fast userspace backend like AF_XDP, netmap, packet socket or
other (or even achieve this through dpdk pmd)
Thanks
next prev parent reply other threads:[~2019-02-12 6:42 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 [this message]
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=b775d7dc-4def-6d7c-ebff-d0b18169c52b@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).