From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:48951)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <willemb@google.com>) id 1cBSkc-0000Xf-MP
	for qemu-devel@nongnu.org; Mon, 28 Nov 2016 15:42:11 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <willemb@google.com>) id 1cBSkb-0004Ga-GW
	for qemu-devel@nongnu.org; Mon, 28 Nov 2016 15:42:10 -0500
Received: from mail-vk0-x22d.google.com ([2607:f8b0:400c:c05::22d]:33819)
	by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16)
	(Exim 4.71) (envelope-from <willemb@google.com>) id 1cBSkb-0004FG-8a
	for qemu-devel@nongnu.org; Mon, 28 Nov 2016 15:42:09 -0500
Received: by mail-vk0-x22d.google.com with SMTP id x186so80480012vkd.1
	for <qemu-devel@nongnu.org>; Mon, 28 Nov 2016 12:42:08 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <325f739a-05bd-c437-b9a2-e371a8cbf50d@linux.intel.com>
References: <20161124151225.GA11963@stefanha-x1.localdomain>
	<325f739a-05bd-c437-b9a2-e371a8cbf50d@linux.intel.com>
From: Willem de Bruijn <willemb@google.com>
Date: Mon, 28 Nov 2016 15:41:36 -0500
Message-ID: <CA+FuTScyECHTaNLzZ6Md2U8xv+t4Ej6-xwE8FRVKwQNbK7U1Ow@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [Qemu-devel] Linux kernel polling for QEMU
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Eliezer Tamir <eliezer.tamir@linux.intel.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>, qemu-devel@nongnu.org, Jens Axboe <axboe@fb.com>, Christoph Hellwig <hch@lst.de>, Davide Libenzi <davidel@xmailserver.org>, "Michael S. Tsirkin" <mst@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, Christian Borntraeger <borntraeger@de.ibm.com>, Fam Zheng <famz@redhat.com>, Eric Dumazet <eric.dumazet@gmail.com>

On Mon, Nov 28, 2016 at 4:31 AM, Eliezer Tamir
<eliezer.tamir@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.