From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752282AbcEJUl2 (ORCPT ); Tue, 10 May 2016 16:41:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39800 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750922AbcEJUl1 (ORCPT ); Tue, 10 May 2016 16:41:27 -0400 Message-ID: <1462912881.9102.0.camel@redhat.com> Subject: Re: [RFC PATCH 0/2] net: threadable napi poll loop From: Paolo Abeni To: Thomas Gleixner Cc: netdev@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jiri Pirko , Daniel Borkmann , Alexei Starovoitov , Alexander Duyck , Tom Herbert , Peter Zijlstra , Ingo Molnar , Rik van Riel , Hannes Frederic Sowa , linux-kernel@vger.kernel.org Date: Tue, 10 May 2016 22:41:21 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 10 May 2016 20:41:26 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2016-05-10 at 17:57 +0200, Thomas Gleixner wrote: > On Tue, 10 May 2016, Paolo Abeni wrote: > > Nice patch set and very promising results! > > > At this point we are not really sure if we should go with this simpler > > approach by putting NAPI itself into kthreads or leverage the threadirqs > > function by putting the whole interrupt into a thread and signaling NAPI > > that it does not reschedule itself in a softirq but to simply run at > > this particular context of the interrupt handler. > > > > While the threaded irq way seems to better integrate into the kernel and > > also other devices could move their interrupts into the threads easily > > on a common policy, we don't know how to really express the necessary > > knobs with the current device driver model (module parameters, sysfs > > attributes, etc.). This is where we would like to hear some opinions. > > NAPI would e.g. have to query the kernel if the particular IRQ/MSI if it > > should be scheduled in a softirq or in a thread, so we don't have to > > rewrite all device drivers. This might even be needed on a per rx-queue > > granularity. > > Utilizing threaded irqs should be halfways simple even without touching the > device driver at all. > > We can do the switch to threading in two ways: > > 1) Let the driver request the interrupt(s) as it does now and then have a > /proc/irq/NNN/threaded file which converts it to a threaded interrupt on > the fly. That should be fairly trivial. > > 2) Let the driver request the interrupt(s) as it does now and retrieve the > interrupt number which belongs to the device/queue from the network core > and let the irq core switch it over to threaded. Thank you for the feedback. We actually experimented something similar to (2). In our implementation we needed a per device chunk of code to do the actual irq number -> queue mapping (and than we performed as well the switch in the device code). > You surely need some way to figure out whether the interrupt is threaded when > you set up the device in order to flag your napi struct, but that should be > not too hard to achieve. This is the part that required per device changes and complicated a bit the implementation. We can research further to simplify it, according to the overall discussion. Cheers, Paolo