On Tue, Apr 9, 2013 at 2:37 AM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Mon, 2013-04-08 at 12:57 -0700, Thomas Pedersen wrote: > >> > That seems racy? Even asking whether it's stopped is racy though, what >> > are you even trying to accomplish? >> >> Yeah, that's why I'd like to get the reason the first time. >> >> _h_mesh_fwding() checks whether the outgoing queue is stopped, to >> avoid piling frames on the pending queue if the outgoing medium is >> busy. I guess the idea was to avoid queueing frames faster than the >> hardware could unload them. Maybe this doesn't actually happen, but we >> can be a little bit smarter about when to drop forwarded frames. Like >> if skbs are just being added to the outgoing queue, we probably >> shouldn't. > > Technically I guess that can happen if your inbound link is better than > the outbound one? But it'll depend on the AC parameters etc. too. > > However it seems that ieee80211_queue_stopped() is actually kinda broken > and should only return the 'driver-stopped' reason to start with. If you > fix that, it's probably good enough for you. I don't think in patch 4 > you should drop frames for scanning, for example. It looks like mac80211 already just checks local->queue_stop_reasons for being 0 (or not), so that check would still hold. I'm not 100% sure the driver calls to ieee80211_queue_stopped() only returning true for REASON_DRIVER are ok? What if the queues are being flushed, or say REASON_PS is set? -- Thomas -- 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
