[ath9k-devel] [PATCH 7/7] ath10k: detect htt pending tx limit at runtime

[Felix Fietkau <nbd@openwrt.org>]

On 2013-05-16 11:09 AM, Michal Kazior wrote:
> The real limit for sending htt tx is either
> msdu_id storage type (u16 - 65536 different
> values) or the HIF tx pipe queue length (2047 in
> case of our PCI HIF).
> 
> The htt tx pipe does not use interrupts - it must
> be polled. It is polled either on RX
> unconditionally or on TX if HIF tx pipe has used
> over 50% of the resources.
> 
> With this patch we should finally trigger the TX
> polling properly. What this really means we should
> have a smoother tx. Not because the tx limit is
> greater, but simply because we'll be triggering
> the polling properly in case of heavy tx.
> 
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
I think a queue length of 2047 is completely excessive. It causes way
too much buffering and latency under load, and I suspect it may be
significantly hurting TCP throughput as well (if TCP manages to get the
queue filled up).
As long as there is no way to dynamically determine a *reasonable* queue
size, introducing an arbitrary limit is *much* better than just letting
the firmware gobble up as much as it wants.
For reference: ath9k limits the number of pending tx packets to 128 per
WMM queue, and even at the highest MCS rates with 3x3 and HT40 this is
much more than what's actually needed.

- Felix