interrupt coalescing / polling

[Fred Young]

There's an interesting article at:
    http://www.research.digital.com/wrl/publications/abstracts/95.8.html
that talks about limiting the input interrupt arrival rate by disabling
input interrupts during periods when there's a lot of input packets queued
but unprocessed.

-----Original Message-----
From: Donald Becker <becker@cesdis1.gsfc.nasa.gov>
To: John Plevyak <jplevyak@inktomi.com>
Cc: John Plevyak <jplevyak@inktomi.com>;
linux-eepro100@beowulf.gsfc.nasa.gov <linux-eepro100@beowulf.gsfc.nasa.gov>
Date: Fri Feb 26 09:42:21 1999
Subject: Re: interrupt coalescing / polling


>On Thu, 25 Feb 1999, John Plevyak wrote:
>
>> I am considering studying the interrupt overhead on the receive side.
>> I'll keep you informed.
>
>That's an excellent thing to do.
>
>> What do you think about under high load avoiding the interrupts
>> entirely and running off the timer interrupt?
>
>It's bad for latency, but that's mitigated if you only do it under high
>load.
>The normal timer interrupts are too coarse for a reasonable polling mode.
>
>Some cards have internal timers that can be used for this.
>I think the EEPro100 has one as well.
>
>The idea is that when you are handling too much work, or have taken too
many
>interrupts recently (both hard to characterize), you disable all interrupt
>sources except for the card's timer interrupt.  When the timer goes off you
>process the packets and either set the timer again or re-enable interrupts.
>
>The Rx ring size should be increased from the default 32, to a size that
>a little more than you can receive in a polling tick.  You want the
hardware
>rather than the software to discard packets when you are exceptionally
busy,
>although that's difficult to get right unless you peek at how full the
>protocol input queue is.
>
>I implemented a sleazy version of this in the 3c59x driver, but older 3c590
>cards didn't have timers so I didn't do it correctly.  All of my drivers
>have interrupt work limits, which is an ideal place to put such interrupt
>rate mitigation code.
>
>I've also implemented a polling-mode-only Tulip driver for PowerBooks with
>broken interrupt controllers, but that was a hack to get it working rather
>than an attempt to lower system overhead.
>
>> Is there a configuration variable to turn off receive interrupts?
>
>Unlike most chips the EEPro100 has only a global interrupt mask, not
>individual interrupt enables.  You would have to turn off the interrupt
bits
>on the receive descriptor list.
>
>Donald Becker   becker@cesdis.gsfc.nasa.gov
>USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
>Code 930.5, Goddard Space Flight Center,  Greenbelt, MD.  20771
>301-286-0882      http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
>
>