From: Paolo Abeni <pabeni@redhat•com>
To: Thomas Gleixner <tglx@linutronix•de>
Cc: netdev@vger•kernel.org, "David S. Miller" <davem@davemloft•net>,
Eric Dumazet <edumazet@google•com>,
Jiri Pirko <jiri@mellanox•com>,
Daniel Borkmann <daniel@iogearbox•net>,
Alexei Starovoitov <ast@plumgrid•com>,
Alexander Duyck <aduyck@mirantis•com>,
Tom Herbert <tom@herbertland•com>,
Peter Zijlstra <peterz@infradead•org>,
Ingo Molnar <mingo@kernel•org>, Rik van Riel <riel@redhat•com>,
Hannes Frederic Sowa <hannes@stressinduktion•org>,
linux-kernel@vger•kernel.org
Subject: Re: [RFC PATCH 0/2] net: threadable napi poll loop
Date: Tue, 10 May 2016 22:41:21 +0200 [thread overview]
Message-ID: <1462912881.9102.0.camel@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1605101655100.3540@nanos>
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
prev parent reply other threads:[~2016-05-10 20:41 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-10 14:11 [RFC PATCH 0/2] net: threadable napi poll loop Paolo Abeni
2016-05-10 14:11 ` [RFC PATCH 1/2] net: implement threaded-able napi poll loop support Paolo Abeni
2016-05-10 14:11 ` [RFC PATCH 2/2] net: add sysfs attribute to control napi threaded mode Paolo Abeni
2016-05-10 14:29 ` [RFC PATCH 0/2] net: threadable napi poll loop Eric Dumazet
2016-05-10 15:51 ` David Miller
2016-05-10 16:03 ` Paolo Abeni
2016-05-10 16:08 ` Eric Dumazet
2016-05-10 20:22 ` Paolo Abeni
2016-05-10 20:45 ` David Miller
2016-05-10 20:50 ` Rik van Riel
2016-05-10 20:52 ` David Miller
2016-05-10 21:01 ` Rik van Riel
2016-05-10 20:46 ` Hannes Frederic Sowa
2016-05-10 21:09 ` Eric Dumazet
2016-05-10 21:31 ` Eric Dumazet
2016-05-10 21:35 ` Rik van Riel
2016-05-10 21:53 ` Eric Dumazet
2016-05-10 22:02 ` Eric Dumazet
2016-05-10 22:44 ` Eric Dumazet
2016-05-10 22:02 ` Rik van Riel
2016-05-11 17:55 ` Eric Dumazet
2016-05-10 22:32 ` Hannes Frederic Sowa
2016-05-10 22:51 ` Eric Dumazet
2016-05-11 6:55 ` Peter Zijlstra
2016-05-11 13:13 ` Hannes Frederic Sowa
2016-05-11 14:40 ` Eric Dumazet
2016-05-11 15:01 ` Rik van Riel
2016-05-11 15:50 ` Eric Dumazet
2016-05-11 21:56 ` Eric Dumazet
2016-05-12 20:07 ` Paolo Abeni
2016-05-12 20:49 ` Eric Dumazet
2016-05-12 20:58 ` Paolo Abeni
2016-05-12 21:05 ` Eric Dumazet
2016-05-13 16:50 ` Paolo Abeni
2016-05-13 17:03 ` Eric Dumazet
2016-05-13 17:19 ` Paolo Abeni
2016-05-13 17:36 ` Eric Dumazet
2016-05-16 13:10 ` Paolo Abeni
2016-05-16 13:38 ` Eric Dumazet
2016-05-11 9:48 ` Paolo Abeni
2016-05-11 13:08 ` Eric Dumazet
2016-05-11 13:39 ` Hannes Frederic Sowa
2016-05-11 13:47 ` Hannes Frederic Sowa
2016-05-11 14:38 ` Paolo Abeni
2016-05-11 14:45 ` Eric Dumazet
2016-05-11 22:47 ` Hannes Frederic Sowa
2016-05-10 15:57 ` Thomas Gleixner
2016-05-10 20:41 ` Paolo Abeni [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1462912881.9102.0.camel@redhat.com \
--to=pabeni@redhat$(echo .)com \
--cc=aduyck@mirantis$(echo .)com \
--cc=ast@plumgrid$(echo .)com \
--cc=daniel@iogearbox$(echo .)net \
--cc=davem@davemloft$(echo .)net \
--cc=edumazet@google$(echo .)com \
--cc=hannes@stressinduktion$(echo .)org \
--cc=jiri@mellanox$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=mingo@kernel$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=peterz@infradead$(echo .)org \
--cc=riel@redhat$(echo .)com \
--cc=tglx@linutronix$(echo .)de \
--cc=tom@herbertland$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox