On Mon, Nov 28, 2016 at 4:31 AM, Eliezer Tamir <eliezer.ta...@linux.intel.com> wrote: > + Eric, Willem > > On 24/11/2016 17:12, Stefan Hajnoczi wrote: >> I looked through the socket SO_BUSY_POLL and blk_mq poll support in >> recent Linux kernels with an eye towards integrating the ongoing QEMU >> polling work. The main missing feature is eventfd polling support which >> I describe below. > ... >> State of polling in Linux >> ------------------------- >> SO_BUSY_POLL causes recvmsg(2), select(2), and poll(2) family system >> calls to spin awaiting new receive packets. From what I can tell epoll >> is not supported so that system call will sleep without polling. > > At the time I sent out an RFC for epoll() SO_BUSY_POLL support. > https://lkml.org/lkml/2013/8/21/192 > > In hindsight I think the way I tracked sockets was over-complicated. > What I would do today would be to extend the API to allow the user > to tell epoll which socket/queue combinations are interesting.
Also note the trivial special case for setups with one single-queue nic (most 1Gb machines). On multi-queue setups a less trivial attempt is optimistically spinning on queues whose interrupt is pinned to same cpu as the process. Based on the heuristic that a process that cares enough about low-latency to configure busy poll will also care enough to set cpu affinity. Both heuristics can be implemented without an explicit user API.
