Messages in this thread |  | | Date | Mon, 25 Sep 2000 20:56:01 +0200 | From | Henner Eisen <> | Subject | Re: [PATCH/RFC] (long) network interface changes |
| |
>>>>> "jamal" == jamal <hadi@cyberus.ca> writes: >> 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. >>
jamal> So i would prefer to leave this turned off. Infact i was jamal> hoping to take it off for the final code submission. If you jamal> insist, it could be left there and enabled during
No, I donŽt insist. This was just some brain-storming ;).
[...]
jamal> IPV4 as well. In the case of V6 and V4 it is called jamal> ECN. causing quiet a bit of havoc right now ;-> I can see jamal> the netif_rx() feedback clearly fitting in the 'receive jamal> busy/not-ready' details you talked about earlier. I dont jamal> see the CN fit clearly. Maybe one way is to set the Frame jamal> Relay FECN bit after you return from netif_rx()? callbacks? jamal> nah, too complicated...
I think setting CN bits appropriatlely is the task of the upper layer protocol anyway. The only thing is that the upper layers need to know whether the input queue is congested. Maybe the netif_rx() code could set an skb->rx_congested bit when it delivers packets to the upper layer while the backlog queue is in congested state. (Maybe not really necessary, the upper layer could also query the congestion state by atomic_read(&netdev_dropping)).
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/
|  |