netdev
[Top] [All Lists]

Re: Q: sock output serialization

To: alan@xxxxxxxxxxxxxxxxxxx
Subject: Re: Q: sock output serialization
From: Henner Eisen <eis@xxxxxxxxxxxxx>
Date: Sat, 16 Sep 2000 23:39:45 +0200
Cc: davem@xxxxxxxxxx, kuznet@xxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <E13a3yj-0008E6-00@the-village.bc.nu> (message from Alan Cox on Fri, 15 Sep 2000 23:29:03 +0100 (BST))
References: <E13a3yj-0008E6-00@the-village.bc.nu>
Sender: owner-netdev@xxxxxxxxxxx
Hi,

>>>>> "Alan" == Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> writes:

    >> However, for drivers which support intelligent controllers
    >> (with lapb in firmware) this is not an option and the problem
    >> will persist.

    Alan> 'Smart hardware is broken' repeat .. ;) - but yes its an
    Alan> issue there. These cards could bypass netif_rx and call
    Alan> directly to the lapb top end though ?

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.

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

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.

Henner

<Prev in Thread] Current Thread [Next in Thread>