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 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:14 EST