On Wed, 20 Sep 2000, Henner Eisen wrote:
[some suggestions for the next re-incarnation of the doc deleted]
>
> 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.
>
So i would prefer to leave this turned off. Infact i was hoping to take it
off for the final code submission. If you insist, it could be left there
and enabled during compile. There could be better ways to do it but
experimentation is required.
It will definetely help in the case of low and high speed devices.
> 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.
IPV4 as well. In the case of V6 and V4 it is called ECN. causing
quiet a bit of havoc right now ;->
I can see the netif_rx() feedback clearly fitting in the 'receive
busy/not-ready' details you talked about earlier. I dont see the CN fit
clearly.
Maybe one way is to set the Frame Relay FECN bit after you return from
netif_rx()? callbacks? nah, too complicated...
> 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).
>
Good idea.
There is some mapping e.g.
NET_RX_SUCCESS maps to BLG_CNG_NONE
NET_RX_DROP maps to BLG_CNG_DROP
NET_*_POLICED and NET_*_BYPASS have no proper mapping in the receive
path but we could define them as well
Only difference i see are that we will need several NET_RX_CN defines
because we have BLG_CNG_LOW, BLG_CNG_MOD and BLG_CNG_HIGH
so a NET_RX_CN_LOW, NET_RX_CN_MOD and NET_RX_CN_HIGH would complete it.
> Would it possibe to make the return sematics of the varios
> layer-boundary-crossing methods conssitent ore are they just to
> different?
Doesnt sound like a bad idea. Maybe Davem and/or Alexey and/or Andi can
comment.
> 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 think the initial idea with the transmit path (not sure how alive the
idea is) was to propagate the return codes from the link layer all the way
to the protocol layer. For example it would help TCP to know of
NET_TXMIT_DROP to maybe doing something smarter than go into a FR or an
RTO.
>
> I´ll be leaving for Linux-Kongress. Thus, I won´t be able to
> further contribute to this thread for this week.
What kind of Linux conference gives you no access to the internet? ;->
cheers,
jamal
-
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/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:22 EST