Actually, a few more comments just occurred to me... On Fri, Feb 18, 2011 at 1:21 PM, John W. Linville <linville@xxxxxxxxxxxxx> wrote: > Johannes' comment about tx status reporting being unreliable (and what > he was really saying) finally sunk-in. ÂSo, this version uses > skb->destructor to track in-flight fragments. ÂThat should handle > fragments that get silently dropped in the driver for whatever reason > without leaking queue capacity. ÂCorrect me if I'm wrong! Should we be somehow filtering out and ignoring the packets that get dropped, when we're calculating the average packet transmission rate? Presumably they're getting dropped almost instantly, so they don't really take up queue space and they have abnormally fast transmission times, which will tend to cause us to overestimate max_enqueued? They should be rare, though, at least. (And presumably we *should* include packets that get dropped because their retry timer ran out, since they were sitting in the queue for that long.) Possibly we should just ignore any packet that was handled in less than, oh, say, a few microseconds? Alternatively, if we aren't worried about those packets, then is there any reason this patch should be mac80211 specific? > +static void ieee80211_tx_skb_free(struct sk_buff *skb) > +{ > + Â Â Â struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(skb->dev); > + Â Â Â struct ieee80211_local *local = sdata->local; > + Â Â Â int q = skb_get_queue_mapping(skb); > + > + Â Â Â /* decrement enqueued count */ > + Â Â Â atomic_dec(&sdata->qdata[q].enqueued); > + > + Â Â Â /* if queue stopped, wake it */ > + Â Â Â if (ieee80211_queue_stopped(&local->hw, q)) > + Â Â Â Â Â Â Â ieee80211_wake_queue(&local->hw, q); > +} I think you need to check that .enqueued is < max_enqueued here, instead of waking the queue unconditionally. Suppose the data rate drops while there's a steady flow -- our max_enqueued value will drop below the current queue size, but because we wake the queue unconditionally after each packet goes out, and then only stop it again after we've queued at least one new packet, we might get 'stuck' with an over-large queue. -- Nathaniel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html