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

    On Sun, 20 Sep 1998 wrote:
    > My statement is that exaclty this bad feature allows to get better
    > performance. We have to make as much things as possible on device
    > interrupt, it is proven fact for forwarding. It is almost proven
    > for UDP (though my model is still too poor to be considered seriously).
    > TCP would require too much of work, but it is not impossible.
    > Donald's objection on freezing does not play, because we have
    > hardware flowcontrol (missing in bsd).
    > Clustered interrupt blocking is not drawback, but huge advantage.
    > F.e. with two 100Mbit cards blocking interrupts of second card,
    > while processing interrupt from the first card results in 30% average
    > packet processing reduction. The reason seems to be cache locality.

    Clustered interrupt blocking is just horrible, and not a portable thing to
    depend on anyway.

    Note that Linux already has _exactly_ the right semantics for interrupt
    - when an interrupt handler is in process, that interrupt handler is
    single-threaded. All other interrupts can still happen.

    This means that in a perfect world we could just do all the network packet
    handling inside the network device interrupt, and everybody would be
    happy, because we'd still have good interrupt response times for
    everything else - because we wouldn't be blocking anything else by running
    inside the interrupt. We might still want to throttle the rate to make
    sure we don't starve normal processing, but basically we should still be

    However, there are just too many broken machines out there that do not
    support the above (obviously correct) semantics very well. A lot of
    hardware has a notion of interrupt priorities, and a "higher-priority"
    interrupt will block all lower-priority interrupts. As a result, even
    though the Linux approach to interrupts is supposed to be simple and
    clean, hardware considerations still mean that we do _not_ want to spend
    much time inside the interrupt handler.

    This, btw, is not a PC hardware issue. We can use both the IO-APIC and the
    older PIC essentially without having to care about the priorities by doing
    a "mask+ack" operation at the beginning of the interrupt handling. But
    there are other platforms where you cannot avoid the prioritization.

    And that is why we need to queue the thing, even though queueing does add
    overhead, and allows us to get interrupts faster than we can process them.
    I agree completely with you on that point, it's just that we're limited by
    being portable.

    And btw, for people worrying about SA_INTERRUPT - I'll probably just make
    it go away. It doesn't have any real redeeming features.


    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.021 / U:9.692 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site