Messages in this thread |  | | | Date | Sun, 20 Sep 1998 15:12:11 -0500 | | From | Doug Ledford <> | | Subject | Re: 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/
|  |