Re: [PATCH] mac80211: add an intermediate software queue implementation

[Felix Fietkau <nbd@openwrt.org>]

On 2014-12-16 00:25, Bartosz Szczepanek wrote:
> As for drv_wake_tx_queue and ieee80211_tx_dequeue - is it really
> necessary? There are ieee80211_tx_status and ieee80211_free_txskb
> already, which can be used to decide from mac80211 level when to
> dequeue packet. It could be used even in case of drivers that are not
> aware of new mechanism at all. We could compute difference between
> drv_tx and tx_status/free_txskb calls, therefore getting number of
> frames in HW. What could help us to keep queues short.
Keeping the driver queue short is a bad idea if the driver needs deeper
queues to do aggregation.

> I've already written some code. This http://pastebin.com/dSd1zWt7 is
> patch that implements counter of frames in hardware in the way
> described above. It was necessary to differentiate between free_txskb
> and free_txskb. Information about frames in HW is exported to debugfs.
> I thought I could submit it, but just now did I found this thread, so
> I hope that it's adequate place to propose that. I tested it on ath5k
> and brcmsmac.
For aggregation, different drivers need different kinds of scheduling.
Only packets belonging to the same sta/tid can be aggregated, and in AP
mode you can have concurrent traffic of multiple different sta/tid.
The only way to keep queues really short in that case without
sacrificing throughput is to let the aggregation code fetch packets
directly from sta/tid queues.
With ath5k there is no aggregation yet (we could add A-MSDU at some
point), and with brcmsmac, the driver has an internal layer of queueing
to create per-sta/tid queues.
What I'm proposing is having per-sta/tid queues that are shared between
mac80211 and the driver, which will significantly improve queue
management compared to having multiple competing layers of queueing.

> One more thing - why not to use local->pending for holding packets?
> There is tx_pending tasklet already. I'm not sure if I understand the
> idea of local->pending queues correctly, but it seems to be a bit
> incoherent to have both pending and proposed ieee80211_txq.
local->pending is useless for normal tx queueing purposes, because it's
not per-sta/tid.

- Felix