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.kaz...@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 _______________________________________________ ath9k-devel mailing list ath9k-devel@lists.ath9k.org https://lists.ath9k.org/mailman/listinfo/ath9k-devel
