Three questions about busy poll

Three questions about busy poll

[Cong Wang]

Hello,

While looking into the busy polling in Linux kernel, three questions
come into my mind:

1. In the document[1], it claims sysctl.net.busy_poll depends on
either SO_BUSY_POLL or sysctl.net.busy_read. However, from the code in
ep_set_busy_poll_napi_id(), I don't see such a dependency. It simply
checks sysctl_net_busy_poll and sk->sk_napi_id, but sk->sk_napi_id is
always set as long as we enable CONFIG_NET_RX_BUSY_POLL. So what I am
missing here?

2. Why there is no socket option for sysctl.net.busy_poll? Clearly
sysctl_net_busy_poll is global and SO_BUSY_POLL only works for
sysctl.net.busy_read.

3. How is SO_INCOMING_NAPI_ID supposed to be used? I can't find any
useful documents online. Any example or more detailed doc?


Thanks!

1. https://www.kernel.org/doc/Documentation/sysctl/net.txt

Re: Three questions about busy poll

[Willem de Bruijn]

On Thu, Feb 14, 2019 at 3:15 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> Hello,
>
> While looking into the busy polling in Linux kernel, three questions
> come into my mind:
>
> 1. In the document[1], it claims sysctl.net.busy_poll depends on
> either SO_BUSY_POLL or sysctl.net.busy_read. However, from the code in
> ep_set_busy_poll_napi_id(), I don't see such a dependency. It simply
> checks sysctl_net_busy_poll and sk->sk_napi_id, but sk->sk_napi_id is
> always set as long as we enable CONFIG_NET_RX_BUSY_POLL. So what I am
> missing here?

That documentation refers to sock_poll. This does call sk_busy_loop
individually on each socket in the pollset and thus respects those values.
Epoll was added later, after both sock_poll and that documentation.

> 2. Why there is no socket option for sysctl.net.busy_poll? Clearly
> sysctl_net_busy_poll is global and SO_BUSY_POLL only works for
> sysctl.net.busy_read.

I guess because of how sock_poll works. In that case it is not needed.
The poll duration applies more to the pollset than any of the
individual sockets, too.

> 3. How is SO_INCOMING_NAPI_ID supposed to be used? I can't find any
> useful documents online. Any example or more detailed doc?

From the commit message of 6d4339028b35 ("net: Introduce
SO_INCOMING_NAPI_ID") it sounds like a sharding mechanism that
maintains flow affinity by sharding based on rxqueue (assuming that
something like RSS was used to ensure flow affinity in the first
place).

Re: Three questions about busy poll

[Cong Wang]

On Thu, Feb 14, 2019 at 4:39 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> On Thu, Feb 14, 2019 at 3:15 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
> >
> > Hello,
> >
> > While looking into the busy polling in Linux kernel, three questions
> > come into my mind:
> >
> > 1. In the document[1], it claims sysctl.net.busy_poll depends on
> > either SO_BUSY_POLL or sysctl.net.busy_read. However, from the code in
> > ep_set_busy_poll_napi_id(), I don't see such a dependency. It simply
> > checks sysctl_net_busy_poll and sk->sk_napi_id, but sk->sk_napi_id is
> > always set as long as we enable CONFIG_NET_RX_BUSY_POLL. So what I am
> > missing here?
>
> That documentation refers to sock_poll. This does call sk_busy_loop
> individually on each socket in the pollset and thus respects those values.
> Epoll was added later, after both sock_poll and that documentation.


Ah, yeah, this explains my confusion. I thought busy_poll refers to
all polling related syscalls, that is select()/poll()/epoll(), it looks like
epoll() is so special here. Probably we need some clarification in
net.txt.


>
> > 2. Why there is no socket option for sysctl.net.busy_poll? Clearly
> > sysctl_net_busy_poll is global and SO_BUSY_POLL only works for
> > sysctl.net.busy_read.
>
> I guess because of how sock_poll works. In that case it is not needed.
> The poll duration applies more to the pollset than any of the
> individual sockets, too.


Good point, it's probably like struct eventpoll vs. struct epitem.

The reason why I am looking for a per-socket tuning is to minimize
the impact of setting busy_poll. I don't know if it is possible to somehow
make this per-socket via epoll interfaces, perhaps fundamentally
it is impossible?


>
> > 3. How is SO_INCOMING_NAPI_ID supposed to be used? I can't find any
> > useful documents online. Any example or more detailed doc?
>
> From the commit message of 6d4339028b35 ("net: Introduce
> SO_INCOMING_NAPI_ID") it sounds like a sharding mechanism that
> maintains flow affinity by sharding based on rxqueue (assuming that
> something like RSS was used to ensure flow affinity in the first
> place).

That commit message is the only thing I can find too. I kinda
need a formal documentation in man page and hopefully
an example too.

Thanks for your explanations!

Re: Three questions about busy poll

[Cong Wang]

On Thu, Feb 14, 2019 at 4:43 PM Samudrala, Sridhar
<sridhar.samudrala@intel.com> wrote:
>
>
> On 2/14/2019 12:15 PM, Cong Wang wrote:
>
> Hello,
>
> While looking into the busy polling in Linux kernel, three questions
> come into my mind:
>
> 1. In the document[1], it claims sysctl.net.busy_poll depends on
> either SO_BUSY_POLL or sysctl.net.busy_read. However, from the code in
> ep_set_busy_poll_napi_id(), I don't see such a dependency. It simply
> checks sysctl_net_busy_poll and sk->sk_napi_id, but sk->sk_napi_id is
> always set as long as we enable CONFIG_NET_RX_BUSY_POLL. So what I am
> missing here?
>
> epoll based busypoll is only based on global sysctl_net_busy_poll.
> busy_poll value is used with poll()/select()/epoll and and busy_read is used
> with socket recvmsg

Right, I was confused by what the term "poll" refers to.


>
> 2. Why there is no socket option for sysctl.net.busy_poll? Clearly
> sysctl_net_busy_poll is global and SO_BUSY_POLL only works for
> sysctl.net.busy_read.
>
>
> Not sure if it is useful to make it a per socket option. I think it could
> be a per poll/epoll fd option


It is useful, however, from Willem's reply it looks like hard to push it
down from epoll() interface to each socket.

>
> 3. How is SO_INCOMING_NAPI_ID supposed to be used? I can't find any
> useful documents online. Any example or more detailed doc?
>
>
> A app can create one worker thread per device queue and a worker thread
> for an incoming connection can be selected based on SO_INCOMING_NAPI_ID so that
> all connections coming on a queue are processed by the same thread. This will
> allow epoll from a thread to be associated with sockets that receive packets
> from a single queue allowing busy polling.
>

This information is very useful. It also requires each thread pinning to each
CPU/RX queue, right?

Anyway, I will add this information to socket.7 man page.

Thanks!

Re: Three questions about busy poll

[Willem de Bruijn]

> > > 2. Why there is no socket option for sysctl.net.busy_poll? Clearly
> > > sysctl_net_busy_poll is global and SO_BUSY_POLL only works for
> > > sysctl.net.busy_read.
> >
> > I guess because of how sock_poll works. In that case it is not needed.
> > The poll duration applies more to the pollset than any of the
> > individual sockets, too.
>
>
> Good point, it's probably like struct eventpoll vs. struct epitem.
>
> The reason why I am looking for a per-socket tuning is to minimize
> the impact of setting busy_poll. I don't know if it is possible to somehow
> make this per-socket via epoll interfaces, perhaps fundamentally
> it is impossible?

I think it may be possible. The way busy_read and busy_poll work
in sock_poll is that the sum of all (per socket tunable) busy_read
durations on the sockets in the pollset is ~bound by (global) busy_poll.

The epoll implementation is restricted in the sense that it polls only
on one napi_id at a time. Alongside setting ep->napi_id in
ep_set_busy_poll_napi_id, we could also set a new ep field takes
the min of the global busy_poll and sk->sk_ll_usec.

Though I guess you want to be able to poll on a given pollset
without setting the global sysctl_net_busy_poll at all? That
would be a useful feature both for epoll and poll/select. But
definitely requires refining net_busy_loop_on() to optionally
take some state derived from the sockets in the (e)pollset.

Re: Three questions about busy poll

[Cong Wang]

On Fri, Feb 15, 2019 at 2:47 PM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> > > > 2. Why there is no socket option for sysctl.net.busy_poll? Clearly
> > > > sysctl_net_busy_poll is global and SO_BUSY_POLL only works for
> > > > sysctl.net.busy_read.
> > >
> > > I guess because of how sock_poll works. In that case it is not needed.
> > > The poll duration applies more to the pollset than any of the
> > > individual sockets, too.
> >
> >
> > Good point, it's probably like struct eventpoll vs. struct epitem.
> >
> > The reason why I am looking for a per-socket tuning is to minimize
> > the impact of setting busy_poll. I don't know if it is possible to somehow
> > make this per-socket via epoll interfaces, perhaps fundamentally
> > it is impossible?
>
> I think it may be possible. The way busy_read and busy_poll work
> in sock_poll is that the sum of all (per socket tunable) busy_read
> durations on the sockets in the pollset is ~bound by (global) busy_poll.


Good idea!!

I was actually thinking about checking sk->sk_ll_usec
ep_set_busy_poll_napi_id(). Your idea sounds better than mine.
Maybe we can do both together. :)


>
> The epoll implementation is restricted in the sense that it polls only
> on one napi_id at a time. Alongside setting ep->napi_id in
> ep_set_busy_poll_napi_id, we could also set a new ep field takes
> the min of the global busy_poll and sk->sk_ll_usec.
>
> Though I guess you want to be able to poll on a given pollset
> without setting the global sysctl_net_busy_poll at all? That
> would be a useful feature both for epoll and poll/select. But
> definitely requires refining net_busy_loop_on() to optionally
> take some state derived from the sockets in the (e)pollset.

Yes, or at least give some control to each application.
I was thinking about this:

diff --git a/fs/eventpoll.c b/fs/eventpoll.c
index a5d219d920e7..1b104c8bda5e 100644
--- a/fs/eventpoll.c
+++ b/fs/eventpoll.c
@@ -432,7 +432,7 @@ static inline void ep_set_busy_poll_napi_id(struct
epitem *epi)
                return;

        sk = sock->sk;
-       if (!sk)
+       if (!sk || !sk->sk_ll_usec)
                return;

        napi_id = READ_ONCE(sk->sk_napi_id);

With this change, busy_poll would rely on either busy_read or
SO_BUSY_POLL.

Does this make any sense?

Thanks.

Re: Three questions about busy poll

[Willem de Bruijn]

On Mon, Feb 18, 2019 at 11:30 PM Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> On Fri, Feb 15, 2019 at 2:47 PM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > > > > 2. Why there is no socket option for sysctl.net.busy_poll? Clearly
> > > > > sysctl_net_busy_poll is global and SO_BUSY_POLL only works for
> > > > > sysctl.net.busy_read.
> > > >
> > > > I guess because of how sock_poll works. In that case it is not needed.
> > > > The poll duration applies more to the pollset than any of the
> > > > individual sockets, too.
> > >
> > >
> > > Good point, it's probably like struct eventpoll vs. struct epitem.
> > >
> > > The reason why I am looking for a per-socket tuning is to minimize
> > > the impact of setting busy_poll. I don't know if it is possible to somehow
> > > make this per-socket via epoll interfaces, perhaps fundamentally
> > > it is impossible?
> >
> > I think it may be possible. The way busy_read and busy_poll work
> > in sock_poll is that the sum of all (per socket tunable) busy_read
> > durations on the sockets in the pollset is ~bound by (global) busy_poll.
>
>
> Good idea!!
>
> I was actually thinking about checking sk->sk_ll_usec
> ep_set_busy_poll_napi_id(). Your idea sounds better than mine.
> Maybe we can do both together. :)
>
>
> >
> > The epoll implementation is restricted in the sense that it polls only
> > on one napi_id at a time. Alongside setting ep->napi_id in
> > ep_set_busy_poll_napi_id, we could also set a new ep field takes
> > the min of the global busy_poll and sk->sk_ll_usec.
> >
> > Though I guess you want to be able to poll on a given pollset
> > without setting the global sysctl_net_busy_poll at all? That
> > would be a useful feature both for epoll and poll/select. But
> > definitely requires refining net_busy_loop_on() to optionally
> > take some state derived from the sockets in the (e)pollset.
>
> Yes, or at least give some control to each application.
> I was thinking about this:
>
> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
> index a5d219d920e7..1b104c8bda5e 100644
> --- a/fs/eventpoll.c
> +++ b/fs/eventpoll.c
> @@ -432,7 +432,7 @@ static inline void ep_set_busy_poll_napi_id(struct
> epitem *epi)
>                 return;
>
>         sk = sock->sk;
> -       if (!sk)
> +       if (!sk || !sk->sk_ll_usec)
>                 return;
>
>         napi_id = READ_ONCE(sk->sk_napi_id);
>
> With this change, busy_poll would rely on either busy_read or
> SO_BUSY_POLL.
>
> Does this make any sense?

The main issue I see would be in doing it unconditionally, changing
existing behavior.

Perhaps we can add a socket flag and replace the e()pollset busy poll
budget with sk->sk_ll_usec if set? The pollsets would need private
fields initialized from sysctl_net_busy_poll. This also allows
selectively enabling busy polling while leaving global
net_core_busy_poll zero otherwise.

This flag could for instance be passed through SO_BUSY_POLL by
accepting an optlen of 2*sizeof(int).

Just a thought. This is quickly getting a lot more complex than a nice
one-line patch.

Re: Three questions about busy poll

[Samudrala, Sridhar]

On 2/15/2019 11:18 AM, Cong Wang wrote:
> On Thu, Feb 14, 2019 at 4:43 PM Samudrala, Sridhar
> <sridhar.samudrala@intel.com> wrote:
>>
>> On 2/14/2019 12:15 PM, Cong Wang wrote:
>>
>> Hello,
>>
>> While looking into the busy polling in Linux kernel, three questions
>> come into my mind:
>>
>> 1. In the document[1], it claims sysctl.net.busy_poll depends on
>> either SO_BUSY_POLL or sysctl.net.busy_read. However, from the code in
>> ep_set_busy_poll_napi_id(), I don't see such a dependency. It simply
>> checks sysctl_net_busy_poll and sk->sk_napi_id, but sk->sk_napi_id is
>> always set as long as we enable CONFIG_NET_RX_BUSY_POLL. So what I am
>> missing here?
>>
>> epoll based busypoll is only based on global sysctl_net_busy_poll.
>> busy_poll value is used with poll()/select()/epoll and and busy_read is used
>> with socket recvmsg
> Right, I was confused by what the term "poll" refers to.
>
>
>> 2. Why there is no socket option for sysctl.net.busy_poll? Clearly
>> sysctl_net_busy_poll is global and SO_BUSY_POLL only works for
>> sysctl.net.busy_read.
>>
>>
>> Not sure if it is useful to make it a per socket option. I think it could
>> be a per poll/epoll fd option
>
> It is useful, however, from Willem's reply it looks like hard to push it
> down from epoll() interface to each socket.
>
>> 3. How is SO_INCOMING_NAPI_ID supposed to be used? I can't find any
>> useful documents online. Any example or more detailed doc?
>>
>>
>> A app can create one worker thread per device queue and a worker thread
>> for an incoming connection can be selected based on SO_INCOMING_NAPI_ID so that
>> all connections coming on a queue are processed by the same thread. This will
>> allow epoll from a thread to be associated with sockets that receive packets
>> from a single queue allowing busy polling.
>>
> This information is very useful. It also requires each thread pinning to each
> CPU/RX queue, right?
Thread pinning will not be required if XPS is setup to use xps-rxqs that 
allows
configuring symmetric queues so that tx-queue is selected based on rx-queue.
See XPS using receive queues map in Documentation/networking/scaling.txt
>
> Anyway, I will add this information to socket.7 man page.
>
> Thanks!