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