> So I think it's more a case of
> - we may want to change the way incoming packets are handled to make it
> perform better
> and
> - we may want to throttle excessive incoming interrupts
Yes. It is clean and precise formulation of the problem.
The second problem is relatively easy and solved by CONFIG_NET_HW_FLOWCONTROL.
This element is necessary, it already presents, helps partially
and already hit its limits. It has one fundamental limitation:
when processing of one packet INSIDE device interrupt routine
exceeds inter packet gap (200MHz P-II and one 100Mbit interface
already hits this boundary), it does not work.
It is very easy to solve by throttling inside *_interrupt and
by scheduling wakeup timer also inside *_interrupt.
The first problem is more fundamental. Seems, my question
about spl was too cryptic (as usually, I was lazy to explain)
and you misunderstood me. All the things said in responses are correct,
but only Donald's reply was close to the thing, which I really meaned.
BSD spls are bad, because too much of things are made on splimpl()
without necessary flow control.
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.
I'd formulate main (not proven) theorem on high speed networking as:
Theorem
-------
If you get a packet, please, make all that you can make
with it without any queeing. If you will queue, you multiply
one packet cost by factor 2..infinity. It is safe, provided
hw flowcontrol works and latency sensitive irqs have higher
priority.
Well, I try to prove that this theorem is wrong (it would be superb,
because it would allow simpler solutions) almost for year,
but all byproduct lemmas (CONFIG_NET_{HW_FLOWCONTROL,FASTROUTE,UDP_DELAY_CSUM},
experimenet with fastpath udp) force to suspect, that it is correct yet.
Alexey
-
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/