Re: [PATCH 2/2] ath10k: Set sk_pacing_shift to 6 for 11AC WiFi chips

["Michał Kazior" <kazikcz@gmail.com>]

On 27 July 2018 at 11:39, Wen Gong <wgong@codeaurora.org> wrote:
> On 2018-07-26 21:02, Micha=C5=82 Kazior wrote:
>>
>> On 26 July 2018 at 13:45, Toke H=C3=B8iland-J=C3=B8rgensen <toke@toke.dk=
> wrote:
>>>
>>> Wen Gong <wgong@codeaurora.org> writes:
>>>
>>>> Upstream kernel has an interface to help adjust sk_pacing_shift to hel=
p
>>>> improve TCP UL throughput.
>>>> The sk_pacing_shift is 8 in mac80211, this is based on test with 11N
>>>> WiFi chips with ath9k. For QCA6174/QCA9377 PCI 11AC chips, the 11AC
>>>> VHT80 TCP UL throughput testing result shows 6 is the optimal.
>>>> Overwrite the sk_pacing_shift to 6 in ath10k driver.
>>>
>>>
>>> When I tested this, a pacing shift of 8 was quite close to optimal as
>>> well for ath10k. Why are you getting different results?
>>>
>>>> Tested with QCA6174 PCI with firmware
>>>> WLAN.RM.4.4.1-00109-QCARMSWPZ-1, but this will also affect QCA9377 PCI=
.
>>>> It's not a regression with new firmware releases.
>>>>
>>>> There have 2 test result of different settings:
>>>>
>>>> ARM CPU based device with QCA6174A PCI with different
>>>> sk_pacing_shift:
>>
>>
>> Different firmware releases have different tx buffering
>> characteristics. In some 10.2 firmware running on QCA9888 you can have
>> up to 5ms of delayed aggregation. Ideally sk_pacing_shift should be
>> adjusted per firmware release. Maybe this should become part of the
>> ath10k firmware wrapping "fw features" stuff?
>>
> recently we do not want to do like this since no test data for each
> firmware.

All the more reason to *not* change the pacing shift from 8 to 6 for
entire ath10k because you have no idea what impact that is going to
have on other chips/firmwares, e.g. QCA4019, QCA9888X, QCA9984.


Micha=C5=82