Arend van Spriel <arend.vanspriel@xxxxxxxxxxxx> writes: > On 8/8/2018 9:00 PM, Peter Oh wrote: >> >> >> On 08/08/2018 03:40 AM, Wen Gong wrote: >>> Add a field for ath10k to adjust the sk_pacing_shift, mac80211 set >>> the default value to 8, and ath10k will change it to 6. Then mac80211 >>> will use the changed value 6 as sk_pacing_shift since 6 is the best >>> value for tx throughput by test result. >> I don't think you can convince people with the numbers unless you >> provide latency along with the numbers and also measurement result on >> different chipsets as Michal addressed (QCA4019, QCA9984, etc.) From >> users view point, I also agree on Toke that we cannot scarify latency >> for the small throughput improvement. > > Yeah. The wireless industry (admittedly that is me too :-p ) has been > focused on just throughput long enough. Tell me about it ;) > All the preaching about bufferbloat from Dave and others is (just) > starting to sink in here and there. Yeah, I've noticed; this is good! > Now as for the value of the sk_pacing_shift I think we agree it > depends on the specific device so in that sense the api makes sense, > but I think there are a lot of variables so I was wondering if we > could introduce a sysctl parameter for it. Does that make sense? I'm not sure a sysctl parameter would make sense; for one thing, it would be global for the host, while different network interfaces will probably need different values. And for another, I don't think it's something a user can reasonably be expected to set correctly, and I think it *is* actually possible to pick a value that works well at the driver level. -Toke
