From mboxrd@z Thu Jan 1 00:00:00 1970 From: Felix Fietkau Date: Mon, 03 Jun 2013 10:35:45 +0200 Subject: [ath9k-devel] [PATCH 7/7] ath10k: detect htt pending tx limit at runtime In-Reply-To: <1368695347-18467-8-git-send-email-michal.kazior@tieto.com> References: <1368695347-18467-1-git-send-email-michal.kazior@tieto.com> <1368695347-18467-8-git-send-email-michal.kazior@tieto.com> Message-ID: <51AC5561.7020501@openwrt.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.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 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