[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-tulip
Subject:    Re: Increasing work done per interrupt
From:       Donald Becker <becker () cesdis1 ! gsfc ! nasa ! gov>
Date:       1997-12-08 19:07:32
[Download RAW message or body]

On Mon, 8 Dec 1997, B. James Phillippe wrote:

> 	In the testing I've been doing (with the analyzer), I've found
> that at small frame sizes (less than 256 bytes), the tulip.c 86H spits out
> lots of "Too much work at interrupt" messages, and then I have to
> reinitialize the cards with ifconfig to get them to talk again.

Hmmm, the driver *should* recover from emitting that message.  I'll read the
code again... looks fine.  I'll have to think some more about what could be
going wrong. 

> 	Looking through the driver, I see the boguscnt variable appears to
> be tracking the iterations in tulip_interrupt() before bailing?  It was
> set to 12, and I tried experimenting by setting it to 20 (same value as
> 3c59x.c).  When I run the test now, these messages are quieted and the
> driver can handle small frames en masse without bailing.  It doesn't
> change the speed it handles them at, of course; just seems to make it more
> tolerant.  Is this sane thing to do, and what are the ramifications of
> this change? 

This is the correct thing to do.  I'ved bumped up the default value to 20 in
v0.86I.

The right driver change is
 - to have a better model of the work done
    I should enhance the 'work-done' value to account for actual receive
    work.  That way I can safely increase the value even further.  The
    complication is that Rx work can vary greatly.
 - to limit the actual time in the interrupt by reading a timer
    An internal Tulip timer is available, but not on all chips.

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/pub/people/becker/whoiam.html

[prev in list] [next in list] [prev in thread] [next in thread]