Re: [PATCH/RFC] (long) network interface changes

From: Henner Eisen (eis@baty.hanse.de)
Date: Mon Sep 25 2000 - 13:56:01 EST


>>>>> "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/



This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:16 EST