[Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices
kvalo at codeaurora.org
Thu Nov 9 17:06:41 PST 2017
Adding ath10k list to get this discussion to the list archive.
Dave Taht <dave.taht at gmail.com> writes:
> On Thu, Nov 9, 2017 at 4:10 PM, Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>> Rajkumar Manoharan <rmanohar at qti.qualcomm.com> writes:
>>>> Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the
>>>> mac80211 TXQs for some devices because of a theoretical throughput
>>>> regression. We have not seen this regression for a while now, so it should be
>>>> safe to re-enable TXQs.
>>>> Signed-off-by: Toke Høiland-Jørgensen <toke at toke.dk>
>>>> This has been in LEDE trunk for a couple of months now with good results.
>>> Good to know that the performance drop is not seen with the chips that does not
>>> have push-pull support. The issue was originally reported with ap152 + qca988x
>>> by community . Hope this combination is also considered in LEDE.
>> Ah, was that the original bug report? Thank you, I have not been able to
>> find that anywhere!
>> The issue that seems to point to has been fixed a while ago; I'll send
>> and updated patch with a better commit message (also forgot to cc the
>> ath10k list, I see).
> Hmm. I remember that thread. I thought we'd basically resolved that
> issue (45% of the time spent in fq_codel_drop under udp flood),
> back then, with eric adding the batch drop fix to fq_codel itself:
> See commit: https://osdn.net/projects/android-x86/scm/git/kernel/commits/9d18562a227874289fda8ca5d117d8f503f1dcca
> which fixed up the problem beautifully:
> So if we've been carrying this darn patch for the ath10k vs something
> that we'd actually fixed elsewhere in the stack, for over a year,
More information about the ath10k