[lkml]   [2000]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Q: sock output serialization

    Seems all the good network stuff gets discussed on l-k instead ;-<
    (hint: some people are not subscribed to l-k)

    On Sat, 16 Sep 2000, Henner Eisen wrote:

    > What about a function to query the state of the backlog queue?
    > Something like
    > if(netif_would_drop(dev)){
    > kfree_skb(skb);
    > /*optionally,if supported by lapb implementation:*/
    > set_lapb_rx_busy_condition();
    > return;
    > }
    > clear_lapb_rx_busy_condition(); /* if supported */
    > pass_frame_to_lapb(lapb,skb);
    > The key point is that we need to query the backlog queue and
    > discard the skb before lapb can acknowledge it. Simply discarding
    > it when backlog is known to be congested should be sufficient. It could
    > however improve performance if lapb did additionally flow control the peer.

    This should be resolved by a patch i am about to submit based on the OLS
    netif_rx() now returns a value which tells you the congestion levels when
    you give it a packet (change from void netif_rx())

    /* return values:
    * BLG_CNG_NONE (no congestion)
    * BLG_CNG_LOW (low congestion)
    * BLG_CNG_MOD (moderate congestion)
    * BLG_CNG_HIGH (high congestion)
    * BLG_CNG_DROP (packet was dropped)

    > With the current scheme, lapb first acknowleges reception of the frame
    > and after that, netif_rx() might still discard it -- which is evil.

    This might screw things a bit. Can you defer to say first call
    netif_rx() then acknowledge or is this hard-coded into the f/ware?

    > Provided that netif_would_drop(dev) is reliable (a subsequent netif_rf will
    > reliably not drop the frame), this should make the netif_rx path reliable.
    > It seems that, on 2.4.0, something like
    > int netif_would_drop(dev)
    > {
    > return (queue->input_pkt_queue.qlen > netdev_max_backlog)
    > || ( (queue->input_pkt_queue.qlen) && (queue->throttle) )
    > }
    > would fulfil those requirements.

    I think this would make it a little more complex than necessary; the queue
    state might change right after you return from netif_would_drop() -- maybe
    not, i am just hypothesizing.
    ** You can still create the netif_would_drop() --it just sounds too
    expensive to me since to be realy sure no packet of yours is dropped, you
    have to make this call for every packet.

    If you cant defer the acknowledgement until netif_rx() returns then what
    we could do is instead:

    1) for devices that are registered with hardware flow control
    ==> you have to register as a CONFIG_NET_HW_FLOWCONTROL device.

    a) to let them queue that last packet before they are shut-up, the
    assumption is they respect the protocol and will 'back-off' after
    b) return BLG_CNG_WOULD_DROP instead to the device and give it the
    responsibility to free the skb or store it wherever it wants but not in
    the backlog.

    I personally prefer a). Reason: If we have done all the work so
    far(context switch etc) and we know the device is well behaved(meaning it
    is not going to send another packet without beiong told things are fine)
    then it is probably wiser to just let that packet get on the backlog


    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.023 / U:5.984 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site