[Top][All Lists]

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

Re: [Qemu-devel] [PATCH V3] tap: vhost busy polling support

From: Jason Wang
Subject: Re: [Qemu-devel] [PATCH V3] tap: vhost busy polling support
Date: Wed, 8 Jun 2016 14:43:01 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0

On 2016年06月08日 01:39, Greg Kurz wrote:
On Tue, 31 May 2016 12:43:11 +0800
Jason Wang<address@hidden>  wrote:

>On 2016年05月31日 12:19, Michael S. Tsirkin wrote:
> >On Tue, May 31, 2016 at 11:04:18AM +0800, Jason Wang wrote:
> >>
> >>On 2016年05月31日 02:07, Michael S. Tsirkin wrote:
> >>>On Thu, Apr 07, 2016 at 12:56:24PM +0800, Jason Wang wrote:
> >>>>This patch add the capability of basic vhost net busy polling which is
> >>>>supported by recent kernel. User could configure the maximum number of
> >>>>us that could be spent on busy polling through a new property of tap
> >>>>"vhost-poll-us".
> >>>I applied this but now I had a thought - should we generalize this to
> >>>"poll-us"? Down the road tun could support busy olling just like
> >>>sockets do.
> >>Looks two different things. Socket busy polling depends on the value set by
> >>sysctl or SO_BUSY_POLL, which should be transparent to qemu.
> >This is what I am saying.  qemu can set SO_BUSY_POLL if poll-us is specified,
> >can it not?
>With CAP_NET_ADMIN, it can. Without it, it can only decrease the value.
> >   Onthe one hand this suggests a more generic name
> >for the option.
>I see, but there're some differences:
>- socket busy polling only poll for rx, vhost busy polling poll for both
>tx and rx.
>- vhost busy polling does not depends on socket busy polling, it can
>work with socket busy polling disabled.
FWIW since these are different things, maybe the user would want to use
both (?)... in which case a single API could be painful.

Yes, but since technically we can do busy polling from qemu, so I will post a patch on top to change the name to "poll-us" instead. For now, we will ignore this for userspace network, we may want to add it in the future.


reply via email to

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