Return-path: Received: from mail.vyatta.com ([76.74.103.46]:41691 "EHLO mail.vyatta.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752793AbZIHAOK (ORCPT ); Mon, 7 Sep 2009 20:14:10 -0400 Date: Mon, 7 Sep 2009 17:14:06 -0700 From: Stephen Hemminger To: "Luis R. Rodriguez" Cc: Steven Rostedt , Ingo Molnar , Michael Buesch , "John W. Linville" , linux-wireless , linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Matt Smith , Kevin Hayes , Bob Copeland , Jouni Malinen , Ivan Seskar , ic.felix@gmail.com Subject: Re: Stop using tasklets for bottom halves Message-ID: <20090907171406.6a4b6116@nehalam> In-Reply-To: <43e72e890909071558s637b45c7i10807587dc40e8c4@mail.gmail.com> References: <43e72e890909071558s637b45c7i10807587dc40e8c4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-wireless-owner@vger.kernel.org List-ID: On Mon, 7 Sep 2009 15:58:50 -0700 "Luis R. Rodriguez" 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. --