ath10k performance, master branch from 20160407

[Roman Yeryomin]

On 19 April 2016 at 18:35, Valo, Kalle <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>
>> On 19 April 2016 at 09:31, Roman Yeryomin <leroi.lists at gmail.com> wrote:
>>> On 19 April 2016 at 08:28, Michal Kazior <michal.kazior at tieto.com> 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.

Regards,
Roman