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

[Jason Wang <jasowang@redhat.com>]

On 2016年06月08日 01:39, Greg Kurz wrote:
> On Tue, 31 May 2016 12:43:11 +0800
> Jason Wang<jasowang@redhat.com>  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.

Thanks