Wireless device queues

Typically, wireless devices have four queues for the different access categories, and additionally buffer somewhere for aggregation in HT mode.

Schematically:

Note that the software queues exist for each virtual interface, and the aggregation queue there exists for each aggregation session. The above picture reflects iwlwifi, for ath9k the aggregation queues are in the driver instead but the mapping is identical.

The FIFOs are typically shallow and only used to buffer DMA latencies. In any case, they typically can't be changed anyway.

Aggregation might collect up to 64 frames into a single aggregate, and all those frames must be on the queue first, so those queues should be allowed to get a fair number of frames to allow forming aggregates most effectively; note that some drivers limit the aggregate length to less than 64 (iwlwifi, for example, currently limits it to 31).

iwlwifi also separates virtual interfaces a bit more and gives each of the two virtual interfaces its own set of hardware queues, but that doesn't really make a big difference.

Wireless specific issues

AP

If a wireless device operates as an access point, it can be transmitting to multiple stations at the same time, at very different speeds. If, for example, the link to some station is really bad, a single short frame to it might take more time than a number of longer frames to another station that has better signal.

aggregation

Aggregation is controlled by driver (ath9k) or the device (iwlwifi). There's a potential delay there – packets may be held in preparation for aggregation for some amount of time before they are transmitted so that they can be aggregated at all – if they were just put into the device queue on ath9k they'd all be sent one by one. For iwlwifi the device makes aggregation decisions, but it needs to have a number of frames in the queue to make good ones. However, this complicates estimating the queue airtime since the aggregation decisions aren't known to the driver and the airtime heavily depends on them.

ath9k notes

The amount of TX buffers available are defined statically to 512 but it has been suggested by mtaht on lwn that the following changes help considerably:

--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ a/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -136,10 +136,10 @@

 #define ATH_MAX_ANTENNA         3
 #define ATH_RXBUF               512
-#define ATH_TXBUF               512
+#define ATH_TXBUF               32
 #define ATH_TXBUF_RESERVE       5
 #define ATH_MAX_QDEPTH          (ATH_TXBUF / 4 - ATH_TXBUF_RESERVE)
-#define ATH_TXMAXTRY            13
+#define ATH_TXMAXTRY            4
 #define ATH_MGT_TXMAXTRY        4

 #define TID_TO_WME_AC(_tid)                            \
@@ -193,7 +193,7 @@
        ATH_AGGR_LIMITED,
 };

-#define ATH_TXFIFO_DEPTH 8
+#define ATH_TXFIFO_DEPTH 4
 struct ath_txq {
        int axq_class;
        u32 axq_qnum;

It should be possible to optimize further and even more dynamically change the size based on specific parameters. Specifically one current idea is to use a new adaptive algorithm to change the buffer size. This is being reviewed but patches and other ideas are welcomed.