ath10k performance, master branch from 20160407

Michal Kazior michal.kazior at
Mon May 9 05:26:45 PDT 2016

Hi Roman,

On 22 April 2016 at 19:05, Roman Yeryomin <leroi.lists at> wrote:
> On 19 April 2016 at 18:35, Valo, Kalle <kvalo at> wrote:
>> Michal Kazior <michal.kazior at> writes:
>>> On 19 April 2016 at 09:31, Roman Yeryomin <leroi.lists at> wrote:
>>>> On 19 April 2016 at 08:28, Michal Kazior <michal.kazior at> wrote:
>>>>> If my hunch is right there's no easy (and proper) fix for that now.
>>>>> One of the patchset patches (ath10k: implement wake_tx_queue) starts
>>>>> to use mac80211 software queuing. This introduces extra induced
>>>>> latency and I'm guessing it results in fill-in-then-drain sequences in
>>>>> some cases which end up being long enough to make fq_codel_drop more
>>>>> work than normal.
>>>>> This is required for other changes and MU-MIMO performance
>>>>> improvements so this patch can't be removed.
>>>> But qca988x doesn't support MU-MIMO, AFAIK.
>>> Correct.
>>>> Can this be made chip dependent?
>>> I guess it could but it'd arguably make the driver more complex and
>>> harder to maintain. What we want is a long-term fix, not a short-term
>>> one.
>> But we should never go backwards and TCP dropping from 750 Mbps to ~550
>> Mbps is a huge drop, so this is not ok. We have to do something to fix
>> this, be it reverting the wake_tx_queue support, somehow disabling it by
>> default or something.
> I would agree with Kalle here. This looks like very serious regression.
> But I'm afraid I can only help with testing here.

Can you give the following patch a try, please? I didn't get to
reproduce your problem on a real AP135/AP152 board and instead tried
to simulate a slow uni-proc system via KVM and cooling_device in
sysfs. The patch does improve things in this synthetic setup for me.


More information about the ath10k mailing list