lkml.org 
[lkml]   [1998]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Today Linus redesigns the networking driver interface (was Re: tulip driver in ...)
Donald Becker wrote:
>
> On Sun, 20 Sep 1998, Gerard Roudier wrote:
> > On Sun, 20 Sep 1998, Donald Becker wrote:
> >
> > > And you can fill in my usual flame about people writing drivers that use
> > > SA_INTERRUPT on shared interrupt lines. (Perhaps if they would have been
> > > called "ugly interrupt" instead "fast interrupt"...)
> >
> > There is no semantic problem for a driver to tell the kernel its interrupt
> > code is fast when it is _actually_ fast.

I think this is the semantic problem. The SA_INTERRUPT flag doesn't say
anything about the speed of your interrupt routine. It flags whether or not
to run the various bottom halves at the end of your interrupt. For network
cards, it is required that this flag *not* be set so that the cards
interrupt routine will result in the net bottom half getting run. For SCSI,
with the new SCSI error code in 2.1.x, the same is true, you want to make
sure this flag is not set so that the scsi bottom half will get run at the
end of the interrupt. The only real reason to use the SA_INTERRUPT flag is
if you have an interrupt that's getting entered multiple thousands of times
per second and can't stand the CPU overhead of doing the bottom half
processing (aka, an old standard serial UART running at 115200 baud on a 386
machine, that's what the flag was originally made for). To be honest, I
doubt the ethernet interrupt routines (such as for the tulip) are any slower
in their actual interrupt processing than say my aic7xxx interrupt routine.
I would really hope not since my ethernet card in my news server handles
about 2 interrupts to every 1 for my aic7xxx controllers, so it really
better be the fast interrupt handler since it handles so many more
interrupts. Now, that to me exemplifies why the flag in itself is broken.

Besides, unless you have thirty SCSI busses and hundreds of SCSI devices,
the chances are that you won't break the 300 to 400 interrupt per second
rate on your SCSI subsystem. At that interrupt rate, the SA_INTERRUPT flags
doesn't buy you very much at all, and I would just get rid of it to avoid
the other problems it causes. OTOH, if your interrupt routine services
1000+ interrupts per second, then it might be worthwhile to have the
SA_INTERRUPT flag.

> Yes, SCSI drivers are prime offenders. Many SCSI drivers use "fast"
> interrupt handlers and then do a bunch of work in the interrupt handler.
> (SCSI bus resets, disconnects, etc.)

Only in extreme error conditions thank you :) Besides, when the disks have
quit working and caused a problem bad enough to make the aic7xxx driver blow
the bus away while in an interrupt routine, then you aren't going to be able
to write out any of those packets you might miss anyway so who cares :)
Seriously though, the common code path is fairly lean in my driver anyway,
and I don't use the SA_INTERRUPT flag.


--

Doug Ledford <dledford@dialnet.net>
Opinions expressed are my own, but
they should be everybody's.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:44    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site