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 ...)

Doug,

I know all of the points you mentionned in your mail. My remark about the
semantic of _fast_ was kind of sarcastic remark, but I just forgot the
required smiley.

About the number of interrupts par second I got on my benchmarks, it is
10500 while reading sequentially at the same time a Viking II and a
Cheetah2 connected to a single controller, using 1KB actual IOs, under
2.0.35. That's not real life, but just a benchmark.

It seems that network guys want to do lots of work under interrupt
context, and seem to feel them allowed to do that because they allow other
interrupt to be processed. If that's true, let me tell again that I
disagree with such an approach. I have posted enough on this topic.

Some seem to want to run all the network code in the L1 cache. Am I
getting crazy, or are some network guys brains victimized by some D.O.S
attack ? ;-)

Regards,
Gerard.


On Sun, 20 Sep 1998, Doug Ledford wrote:

> 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    [W:1.047 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site