[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Is IOThread for virtio-net a good idea?

From: Jason Wang
Subject: Re: [Qemu-devel] Is IOThread for virtio-net a good idea?
Date: Wed, 13 Feb 2019 17:38:44 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 2019/2/13 上午2:40, Michael S. Tsirkin wrote:
On Tue, Feb 12, 2019 at 03:00:55PM +0800, Jason Wang wrote:
On 2019/2/12 下午2:48, Jason Wang wrote:
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.

Note, what I did is a vhost implementation inside IOThread. It doesn't use
qemu memory core (which is slow for e.g 10Mpps) but vhost memory table.

If you are going to all these lengths duplicating dpdk I would at least
make it out of process to qemu to improve security.

Well I think I want to do the inverse for easing the access to VM metadata e.g IOMMU or RSS.

As an excercise, maybe start by generalizing pxe test to support vhost
user bridge. That would already be a win.

As for IOTLB, I advicated VTD support in vhost for a while.  VTD page
table parsing isn't a lot of code at all if you put invalidations in
userspace.  We ended up with the message-passing instead for portability
but we can go back for sure.

I think implementing a vendor specific things in vhost is probably not good. And as we've discussed, this will end up duplicating the QI interface through vhost protocol which doesn't help for performance if you move the process out of qemu.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]