[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.021 / U:6.284 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site