On 27 July 2018 at 11:39, Wen Gong <wgong@xxxxxxxxxxxxxx> wrote: > On 2018-07-26 21:02, Michał Kazior wrote: >> >> On 26 July 2018 at 13:45, Toke Høiland-Jørgensen <toke@xxxxxxx> wrote: >>> >>> Wen Gong <wgong@xxxxxxxxxxxxxx> writes: >>> >>>> Upstream kernel has an interface to help adjust sk_pacing_shift to help >>>> 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ł
