[lkml]   [2000]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH/RFC] (long) network interface changes
>>>>> "jamal" == jamal  <> 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)).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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