lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 15 Feb 2019 11:18:29 -0800 From: Cong Wang <xiyou.wangcong@...il.com> To: "Samudrala, Sridhar" <sridhar.samudrala@...el.com> Cc: Alexander Duyck <alexander.duyck@...il.com>, Eric Dumazet <edumazet@...gle.com>, Linux Kernel Network Developers <netdev@...r.kernel.org> Subject: Re: Three questions about busy poll On Thu, Feb 14, 2019 at 4:43 PM Samudrala, Sridhar <sridhar.samudrala@...el.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!
Powered by blists - more mailing lists