Messages in this thread | | | From | kuznet@ms2 ... | Subject | Re: Today Linus redesigns the networking driver interface (was Re: tulip driver in ...) | Date | Sun, 20 Sep 1998 20:56:37 +0400 (MSK DST) |
| |
Hello!
> 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/
| |