Messages in this thread | | | Date | Sun, 20 Sep 1998 10:45:37 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: Today Linus redesigns the networking driver interface (was Re: tulip driver in ...) |
| |
On Sun, 20 Sep 1998 kuznet@ms2.inr.ac.ru 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 handling: - 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 ok.
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.
Linus
- 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/
| |