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
talk.
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
that.
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
queue.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
