netdev
[Top] [All Lists]

Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5

To: jamal <hadi@xxxxxxxxxx>
Subject: Re: [announce] [patch] limiting IRQ load, irq-rewrite-2.4.11-B5
From: Ingo Molnar <mingo@xxxxxxx>
Date: Wed, 3 Oct 2001 19:28:07 +0200 (CEST)
Cc: <linux-kernel@xxxxxxxxxxxxxxx>, Alexey Kuznetsov <kuznet@xxxxxxxxxxxxx>, Robert Olsson <Robert.Olsson@xxxxxxxxxxx>, Benjamin LaHaise <bcrl@xxxxxxxxxx>, <netdev@xxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxx>, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>, Simon Kirby <sim@xxxxxxxxxxxxx>
In-reply-to: <Pine.GSO.4.30.0110031109430.4833-100000@shell.cyberus.ca>
Reply-to: <mingo@xxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
On Wed, 3 Oct 2001, jamal wrote:

> use the netif_rx() return code and hardware flowcontrol to fix it.

i'm using hardware flowcontrol in the patch, but at a different, higher
level. This part of the do_IRQ() code disables the offending IRQ source:

        [...]
        desc->status |= IRQ_MITIGATED|IRQ_PENDING;
        __disable_irq(desc, irq);

which in turn stops that device as well sooner or later. Optionally, in
the future, this can be made more finegrained for chipsets that support
device-independent IRQ mitigation features, like the USB 2.0 EHCI feature
mentioned by David Brownell.

i'd prefer it if all subsystems and drivers in the kernel behaved properly
and limited their IRQ load - but this does not always happen and users are
hit by irq overload situations.

Your NAPI patch, or any driver/subsystem that does flowcontrol accurately
should never be affected by it in any way. No overhead, no performance
hit.

        Ingo


<Prev in Thread] Current Thread [Next in Thread>