[lkml]   [1998]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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 <>
    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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.026 / U:46.372 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site