lkml.org 
[lkml]   [1998]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Today Linus redesigns the networking driver interface (was Re: tulip driver in ...)
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.149 / U:0.364 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site