public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Grant Grundler <iod00d@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Patch] speed up interrupt handling
Date: Fri, 27 Feb 2004 02:47:41 +0000	[thread overview]
Message-ID: <20040227024741.GN15022@cup.hp.com> (raw)
In-Reply-To: <16446.43280.853544.583305@wombat.disy.cse.unsw.edu.au>

On Fri, Feb 27, 2004 at 01:18:56PM +1100, Peter Chubb wrote:
> 
> Hi David,
>    The attached patch makes enable_irq() disappear from the profile.
> From ~4000 cycles per call, it's gone down to around 260 cycles.

wow! cool!

> I've only tested on UP; however, the iosapic lock is held around all
> the manipulations of the new field.

I think that's a great tradeoff.

> This also incidentally increases the performance of the gigabit
> network driver: it drops fewer packets.

Is this related to NAPI?

I'll assume "the gigabit" card is e1000:
static void e1000_netpoll (struct net_device *dev)
{
	struct e1000_adapter *adapter = dev->priv;
	disable_irq(adapter->pdev->irq);
	e1000_intr (adapter->pdev->irq, dev, NULL);
	enable_irq(adapter->pdev->irq);
}

Ok - this will work great on ia64 with this patch.
pktgen should measurably perform better too.
I'll have to try that.

e1000_intr() will need to handle being called twice for
the same device in case it gets invoked on something
other than the same CPU which normally handles it's IRQ.

Not sure how the net stack schedules the poll call but
it's probably worth trying to make sure only one
CPU touches instance data for a NIC card.
Anyone know how to enforce or verify that?
(or want to pursue the question on linux-net mailing list)

Any comments on how efficient disable_irq/enable_irq()
are on other architectures?
I'm just wondering if e1000_netpoll should be the reccomended method
to support NAPI.

thanks,
grant

  reply	other threads:[~2004-02-27  2:47 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-27  2:18 [Patch] speed up interrupt handling Peter Chubb
2004-02-27  2:47 ` Grant Grundler [this message]
2004-02-27  7:11 ` Feldman, Scott
2004-02-27  7:44 ` Peter Chubb
2004-02-27  8:06 ` David Mosberger
2004-02-27 21:27 ` Peter Chubb
2004-02-27 22:22 ` David Mosberger
2004-02-28  4:22 ` Peter Chubb
2004-02-28  5:47 ` David Mosberger
2004-02-28  9:05 ` Mallick, Asit K
2004-02-28 10:21 ` Peter Chubb
2004-02-28 18:24 ` David Mosberger

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=20040227024741.GN15022@cup.hp.com \
    --to=iod00d@hp.com \
    --cc=linux-ia64@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox