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 19:57:56 +0400 (MSK DST) |
| |
Hello!
> Has anybody tried the simple and obvious approach like the above?
I did. BTW this trick was used in 2.1.17+...2.1.68.
I removed it because it did not help.
It resulted in too high and unfair packet loss in pretty common situation, when network peer feeds us with bursts of packets. (BTW it is exactly, which occurs when another Linux 2.1 sends to us)
But major reason, why it did not work: if hardware is not throttled too much of cpu time is spent inside inside device driver, so that net_bh() spins very slowly and ratio served_packets/received_packets falls to zero, practically not depending on threshould.
The only reasonable approach, which I found, is to throttle receivers, when backlog is full, process all queued packets and then unthrottle receiver. (CONFIG_NET_HW_FLOWCONTROL) It appeared very efficient cure, but still not panacea.
About jiffies check. This trick is not intended to solve congestion problem. It is just fallback loop breaker, which allows to make at least some progress, when the things are very bad. Particularly, it is bug trap. Besides that, this break is necessary on slow hardware.
All that you said about CONFIG_NET_CPU_IS_SLOW is truth. It is exactly the reason, why it did not grow to CONFIG_NET_IRED 8)8) (Input RED) However, it really works, when cpu is very slow (386) and interfaces are 10Mbit.
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/
| |