Messages in this thread |  | | Date | Wed, 20 Sep 2000 00:15:34 +0200 | From | Henner Eisen <> | Subject | Re: [PATCH/RFC] (long) network interface changes |
| |
>>>>> "jamal" == jamal <hadi@cyberus.ca> writes:
[...]
Nice introduction!
jamal> The driver uses the feedback information to intelligently jamal> adjust its sending rate. (i.e reduce or increase calls to jamal> netif_rx() or send a congestion-experienced frame to its jamal> peer eg in X.25). In the sample tulip driver, dynamic
Just a clarification (for the next version ;): itŽs not really a congestion notification. It is just a `receiver' busy condition. LAPB is not designed for congestable links and cannot really report that congestion occured. It can only delay acknowledgement (and communicate rx_busy state to the peer). The retransmission was really only designed for occasionally recovering from transmission error caused by line noise. Once a packet has been lost, all packets (even those already arrived after the lost one) must be retransmitted. There is nothing like selcetive acknolegment. Thus, although LAPB can recover from packet loss caused by congestion, it will not react in a manner adapted to the congestion state. For minimizing possible confusion about the different X.25 layers, IŽd suggest to eplicitly call it `LAPB datalink layer of X.25Ž in future versions of the document. jamal> I have experimented with two schemes: one which samples the jamal> queue via a timer and one which does it per-packet and jamal> found that the per-packet sampler gave better results (more jamal> samples, Shannon's theorem applies). It didnt matter jamal> whether HZ was 100 or 1024 during the tests. The measure jamal> of "better" was throughput.
Nice. I think such a kind of fair input queueing would be an important features because that allows to offer a highly reliable netif() to slow links which are slow, but inefficient to handle congestion (like X.25 LAPB datalink protocol). Network interfaces could trade reliablilty for speed.
Another issue: Some protocols designed for congestable links support forward and/or backward congestion notification (e.g. frame relay, I thing DECnet and IPV6 also can do so). Thus, it would be nice if those protocols could easily access the congestion state such that congestion notification bits can be set efficiently.
[...]
Seems there are lots of interesting problems to investigate and to solve. Anyhow, no matter how the details will be in future, WhatŽs basically needed is a return value for netif_rx(). This is also `nice` for symmetry reasons (in 2.4.x, dev_queue_xmit() returns an int, too).
Would it possibe to make the return sematics of the varios layer-boundary-crossing methods conssitent ore are they just to different? There is currently no agreement among the different protocol implementations. Many of them use a boolean return value for reporting whether delivering to upper/lower layer was sucessful. But there is unfortunatly no unique convention whether 1 means success or failure.
IŽll be leaving for Linux-Kongress. Thus, I wonŽt be able to further contribute to this thread for this week.
Cheers,
Henner - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |