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 for QCA6174/9377 PCI. > > 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: > > sk_pacing_shift throughput(Mbps) CPU utilization > 6 500(-P5) ~75% idle, Focus on CPU1: ~14%idle > 7 454(-P5) ~80% idle, Focus on CPU1: ~4%idle > 8 288 ~90% idle, Focus on CPU1: ~35%idle > 9 ~200 ~92% idle, Focus on CPU1: ~50%idle > > 5G TCP UL VTH80 on X86 platform with QCA6174A PCI with sk_packing_shift > set to 6: > > tcp_limit_output_bytes throughput(Mbps) > default(262144)+1 Stream 336 > default(262144)+2 Streams 558 > default(262144)+3 Streams 584 > default(262144)+4 Streams 602 > default(262144)+5 Streams 598 > changed(2621440)+1 Stream 598 > changed(2621440)+2 Streams 601 You still haven't provided any latency numbers for these tests, which makes it impossible to verify that setting sk_pacing_shift to 6 is the right tradeoff. As I said before, from your numbers I suspect the right setting is actually 7, which would be 10-20ms less latency under load; way more important than ~50 Mbps... -Toke
