On Thu, Feb 14, 2019 at 4:43 PM Samudrala, Sridhar <sridhar.samudr...@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!
