Hi,
>>>>> "Alan" == Alan Cox <alan@lxorguk.ukuu.org.uk> 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
-
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 23 2000 - 21:00:13 EST