qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Virtio Polling Mode


From: Hu Yaohui
Subject: Re: [Qemu-devel] Virtio Polling Mode
Date: Mon, 30 Sep 2013 15:15:21 -0400

Hi Jason,
Thanks for your reply! I am more concerned with polling mode about virtio-blk right now. Later I will focus on polling mode on virtio-net.
I don't know whether the polling mode is already existed for virtio-blk or we should implement it by ourselves if we need this feature.
Thanks for your time!

Best Wishes,
Yaohui Hu


On Sun, Sep 29, 2013 at 5:29 AM, Jason Wang <address@hidden> wrote:
On 09/28/2013 02:56 AM, Hu Yaohui wrote:
> Hi All,
> I am wondering whether virtio has provided polling mode already.
> Instead of sending a event from guest to host through eventfd on guest
> side and inject an interrupt into guest on host side to notify each
> other? Could both sides keep polling the Vring to communicate with
> each other?
> Thanks for your time!
>

For virtio-net, both qemu and driver (at least Linux) mix using polling
and notification. Usually one side will disable the notification from
another side when it gets an interrupt, and then enter the polling mode
until no more buffers submitted from another side. After this it will
enable the interrupts again.

One of the method to improve this a little bit is to do the busy polling
even if there's no new buffers in case the other side will submit one or
more shortly. Linux has implemented this as low latency polling for
network stack (see http://lwn.net/Articles/551284/). It will do busy
polling for a time which can be configured by user. I've played a little
bit of this for both virtio-net and vhost, it can improves the latency
(more obvious for single session test) at the cost of extra cpu
overhead. The key to balance them is to choose time spent on busy
polling correctly. I don't think about it further but maybe we can make
it adaptive.
> Best Wishes,
> Yaohui




reply via email to

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