RE: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices

[Toke Høiland-Jørgensen]

Rajkumar Manoharan  writes:

> Agree.. Even I am not fan of that patch in ath10k. IIRC Michal pushed
> this change as temp one and planned to revert it once it is fixed in
> stack or in driver.
>
> I thought Eric change in fq_codel is meant only for fatty udp flows.
> Forgive my ignorance.

It is, mostly. There's a separate possible issue with TCP performance
that we're looking into, but that is unrelated to TXQs.

-Toke

RE: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices

[Rajkumar Manoharan]

> >
> > 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).
> >
> > -Toke
> 
> 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:
> 
> https://lists.bufferbloat.net/pipermail/make-wifi-fast/2016-May/000590.html
> 
> 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, sigh.
>
Dave,

Agree.. Even I am not fan of that patch in ath10k. IIRC Michal pushed this
change as temp one and planned to revert it once it is fixed in stack or in 
driver.

I thought Eric change in fq_codel is meant only for fatty udp flows. Forgive my 
ignorance.

-Rajkumar

Re: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices

[Kalle Valo]

Adding ath10k list to get this discussion to the list archive.

Dave Taht  writes:

> On Thu, Nov 9, 2017 at 4:10 PM, Toke Høiland-Jørgensen  wrote:
>> Rajkumar Manoharan  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 
 ---
 This has been in LEDE trunk for a couple of months now with good results.

>>> Toke,
>>>
>>> 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 [1]. 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).
>>
>> -Toke
>
> 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:
>
> https://lists.bufferbloat.net/pipermail/make-wifi-fast/2016-May/000590.html
>
> 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,
> sigh.

-- 
Kalle Valo

Re: [Make-wifi-fast] [PATCH] ath10k: Re-enable TXQs for all devices

[Dave Taht]

On Thu, Nov 9, 2017 at 4:10 PM, Toke Høiland-Jørgensen  wrote:
> Rajkumar Manoharan  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 
>>> ---
>>> This has been in LEDE trunk for a couple of months now with good results.
>>>
>> Toke,
>>
>> 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 [1]. 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).
>
> -Toke

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:

https://lists.bufferbloat.net/pipermail/make-wifi-fast/2016-May/000590.html

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,
sigh.

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619