All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jeff@garzik.org>
To: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: netdev@vger.kernel.org, Ayaz Abdulla <aabdulla@nvidia.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 2/5] forcedeth: interrupt handling cleanup
Date: Sun, 07 Oct 2007 07:40:45 -0400	[thread overview]
Message-ID: <4708C5BD.8090402@garzik.org> (raw)
In-Reply-To: <86802c440710062143x3bb801c3obb91292208073588@mail.gmail.com>

Yinghai Lu wrote:
> On 10/6/07, Jeff Garzik <jeff@garzik.org> wrote:
>> commit a606d2a111cdf948da5d69eb1de5526c5c2dafef
>> Author: Jeff Garzik <jeff@garzik.org>
>> Date:   Fri Oct 5 22:56:05 2007 -0400
>>
>>     [netdrvr] forcedeth: interrupt handling cleanup
>>
>>     * nv_nic_irq_optimized() and nv_nic_irq_other() were complete duplicates
>>       of nv_nic_irq(), with the exception of one function call.  Consolidate
>>       all three into a single interrupt handler, deleting a lot of redundant
>>       code.
>>
>>     * greatly simplify irq handler locking.
>>
>>       Prior to this change, the irq handler(s) would acquire and release
>>       np->lock for each action (RX, TX, other events).
>>
>>       For the common case -- RX or TX work -- the lock is always acquired,
>>       making all successive acquire/release combinations largely redundant.
>>
>>       Acquire the lock at the beginning of the irq handler, and release it at
>>       the end of the irq handler.  This is simple, easy, and obvious.
>>
>>     * remove irq handler work loop.
>>
>>       All interesting events emanating from the irq handler either have
>>       their own work loops, or they poke a timer into action.
>>
>>       Therefore, delete the pointless master interrupt handler work loop.
>>
>>     Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
>>
>>  drivers/net/forcedeth.c |  325 +++++++++++-------------------------------------
>>  1 file changed, 77 insertions(+), 248 deletions(-)
>>
> any chance to create three verion irq handlers for ioapic, msi, msi-x...?
> 
> MACRO or inline function?

MSI-X already has its own separate interrupt handlers.  MSI and INTx 
call the same interrupt handling code, like the unmodified driver goes. 
  Creating an MSI-specific irq handler would not save very much AFAICS, 
but I might be missing something.

Do you have ideas/suggestions for a different method?

	Jeff




  reply	other threads:[~2007-10-07 11:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-06 15:12 [PATCH 0/5] forcedeth: several proposed updates for testing Jeff Garzik
2007-10-06 15:13 ` [PATCH 1/5] forcedeth: make NAPI unconditional Jeff Garzik
2007-10-06 15:14 ` [PATCH 2/5] forcedeth: interrupt handling cleanup Jeff Garzik
2007-10-07  4:43   ` Yinghai Lu
2007-10-07 11:40     ` Jeff Garzik [this message]
2007-10-07 19:36       ` Yinghai Lu
2007-10-07 20:07         ` Jeff Garzik
2007-10-07  9:03   ` Ingo Molnar
2007-10-06 15:14 ` [PATCH 3/5] forcedeth: process TX completions using NAPI Jeff Garzik
2007-10-07 14:39   ` Jeff Garzik
2007-10-06 15:14 ` [PATCH 4/5] forcedeth: internal simplification and cleanups Jeff Garzik
2007-10-06 15:15 ` [PATCH 5/5] forcedeth: timer overhaul Jeff Garzik
2007-10-06 15:17 ` [PATCH 0/5] forcedeth: several proposed updates for testing Jeff Garzik
2007-10-06 15:24 ` Jeff Garzik
2007-10-07  9:08 ` Ingo Molnar
2007-10-07 11:34   ` Jeff Garzik
2007-10-07 11:23 ` [PATCH 6/n] forcedeth: protect slow path with mutex Jeff Garzik
2007-10-07 14:40   ` Jeff Garzik
2007-10-07 14:47 ` [PATCH 0/5] forcedeth: several proposed updates for testing Jeff Garzik
2007-10-07 19:39   ` Yinghai Lu
2007-10-07 20:05     ` Jeff Garzik

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=4708C5BD.8090402@garzik.org \
    --to=jeff@garzik.org \
    --cc=aabdulla@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=yhlu.kernel@gmail.com \
    /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.