[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.185 / U:3.648 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site