On Thu, 2017-06-22 at 01:50 +0200, Johannes Berg wrote: > In a number of cases, like management frames, mac80211 will not > put the frame on any TXQ but immediately TX it to the driver. > It'd be nicer to be able to use TXQs for all frames, so add a > "fallback" TXQ. This will serve as a container to be able to > remove all the non-TXQ queueing in mac80211. This patch is completely broken right now. When TXQs are enabled, there's still buffering of frames that are *not* marked with IEEE80211_TX_INTFL_OFFCHAN_TX_OK, and that happens on the ieee80211_tx_frags() path, using the queue_stop_reasons etc. In fact, even the drivers can still ask to buffer such frames by stopping their queues... I want to move all of that over to the TXQs instead, so that we can get rid of that buffering logic. The way to do that would be to not return any frames from TXQs when they're in off-channel state (and drivers can also stop scheduling the queues in those cases). However, if *everything* moves to TXQs, that means we need another TXQ for those frames that are marked with IEEE80211_TX_INTFL_OFFCHAN_TX_OK, so that they can go out at any time. So I think the solution is to add *two* new TXQs in this patch, one for on-channel frames and one for off-channel frames. But that's also awkward when you take into account channel contexts, since all those frames might still need to go to different ones. Perhaps then the better solution would be to have a TXQ per channel context, and one for more the remaining frames that. Yeah, this feels slightly odd - why bother putting frames on a TXQ that shouldn't really be buffered - but it fits better with the model (the hybrid push/pull model we have now is somewhat awkward), and there are other reasons than being off-channel to buffer frames, e.g. if the driver queue got full, or the driver is doing something else where it can't easily handle data frames etc. Thoughts, anyone? johannes
