From: Stephen Hemminger <shemminger@vyatta.com>
To: rostedt@goodmis.org
Cc: "Luis R. Rodriguez" <mcgrof@gmail.com>,
Ingo Molnar <mingo@elte.hu>, Michael Buesch <mb@bu3sch.de>,
"John W. Linville" <linville@tuxdriver.com>,
linux-wireless <linux-wireless@vger.kernel.org>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Matt Smith <Matt.Smith@atheros.com>,
Kevin Hayes <kevin@atheros.com>,
Bob Copeland <me@bobcopeland.com>, Jouni Malinen <j@w1.fi>,
Ivan Seskar <Seskar@winlab.rutgers.edu>,
ic.felix@gmail.com
Subject: Re: Stop using tasklets for bottom halves
Date: Tue, 8 Sep 2009 09:12:52 -0700 [thread overview]
Message-ID: <20090908091252.3e931e0d@nehalam> (raw)
In-Reply-To: <1252376254.21261.2052.camel@gandalf.stny.rr.com>
On Mon, 07 Sep 2009 22:17:34 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> On Mon, 2009-09-07 at 17:14 -0700, Stephen Hemminger wrote:
> > On Mon, 7 Sep 2009 15:58:50 -0700
> > "Luis R. Rodriguez" <mcgrof@gmail.com> wrote:
> >
> > > A while ago I had read about an effort to consider removing tasklets
> > > [1] or at least trying to not use them. I'm unaware of the progress in
> > > this respect but since reading that article have always tried to
> > > evaluate whether or not we need tasklets on wireless drivers. I have
> > > also wondered whether work in irq context in other parts of the kernel
> > > can be moved to process context, a curious example being timers. I'll
> > > personally be trying to using only process context on bottom halves on
> > > future drivers but I figured it may be a good time to ask how serious
> > > was avoiding tasklets or using wrappers in the future to avoid irq
> > > context is or is it advised. Do we have a general agreement this is a
> > > good step forward to take? Has anyone made tests or changes on a
> > > specific driver from irq context to process context and proven there
> > > are no significant advantages of using irq context where you would
> > > have expected it?
> > >
> > > Wireless in particular should IMHO not require taskets for anything
> > > time sensitive that I can think about except perhaps changing channels
> > > quickly and to do that appropriately also process pending RX frames
> > > prior to a switch. It remains to be seen experimentally whether or not
> > > using a workqueue for RX processing would affect the time to switch
> > > channels negatively but I doubt it would be significant. I hope to
> > > test that with ath9k_htc.
> > >
> > > What about gigabit or 10 Gigabit Ethernet drivers ? Do they face any
> > > challenges which would yet need to be proven would not face issues
> > > when processing bottom halves in process context?
> > >
> > > [1] http://lwn.net/Articles/239633/
> > >
> > > Luis
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> > Why not use NAPI, which is soft irq? Almost all 1G and 10G drivers
> > use NAPI.
> >
> > Process context is too slow.
>
> Well, I'm hoping to prove the opposite. I'm working on some stuff that I
> plan to present at Linux Plumbers. I've been too distracted by other
> things, but hopefully I'll have some good numbers to present by then.
>
> -- Steve
>
>
A good performance test is changing the behaviour of loopback
device and running lmbench. This checks overhead without the specter
of real hardware.
--
prev parent reply other threads:[~2009-09-08 16:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-07 22:58 Stop using tasklets for bottom halves Luis R. Rodriguez
2009-09-07 22:58 ` Luis R. Rodriguez
2009-09-08 0:14 ` Stephen Hemminger
2009-09-08 2:17 ` Steven Rostedt
2009-09-08 2:17 ` Steven Rostedt
2009-09-08 4:16 ` Luis R. Rodriguez
2009-09-08 4:16 ` Luis R. Rodriguez
2009-09-08 13:18 ` Steven Rostedt
2009-09-08 13:18 ` Steven Rostedt
2009-09-08 4:50 ` Michael Buesch
2009-09-08 4:50 ` Michael Buesch
2009-09-08 5:08 ` Michael Buesch
2009-09-08 7:10 ` Ingo Molnar
2009-09-08 19:07 ` matthieu castet
2009-09-08 19:12 ` Michael Buesch
2009-09-08 16:11 ` Stephen Hemminger
2009-09-08 16:40 ` Steven Rostedt
2009-09-08 16:40 ` Steven Rostedt
2009-09-08 17:01 ` Stephen Hemminger
2009-09-08 17:27 ` Steven Rostedt
2009-09-08 17:27 ` Steven Rostedt
2009-09-08 16:12 ` Stephen Hemminger [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=20090908091252.3e931e0d@nehalam \
--to=shemminger@vyatta.com \
--cc=Matt.Smith@atheros.com \
--cc=Seskar@winlab.rutgers.edu \
--cc=ic.felix@gmail.com \
--cc=j@w1.fi \
--cc=kevin@atheros.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=mb@bu3sch.de \
--cc=mcgrof@gmail.com \
--cc=me@bobcopeland.com \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.