| Message ID | 20171110004839.7478-1-toke@toke.dk (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 170e8e6176d480717b0603a988ce7e4c1be654a8 |
| Delegated to: | Kalle Valo |
| Headers | show |
On 2017-11-10 01:48, Toke Høiland-Jørgensen wrote: > Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the > mac80211 TXQs for some devices because of a theoretical throughput > regression. The original regression report[1] was related to fq_codel > qdisc drop performance, which was fixed in > 9d18562a227874289fda8ca5d117d8f503f1dcca. Since then, we have not seen > the TXQ-related regression, so it should be safe to re-enable TXQs. That commit is unrelated to the fq/codel implementations in mac80211, since mac80211 with txq does not use qdisc. - Felix
Felix Fietkau <nbd@nbd.name> writes: > On 2017-11-10 01:48, Toke Høiland-Jørgensen wrote: >> Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the >> mac80211 TXQs for some devices because of a theoretical throughput >> regression. The original regression report[1] was related to fq_codel >> qdisc drop performance, which was fixed in >> 9d18562a227874289fda8ca5d117d8f503f1dcca. Since then, we have not seen >> the TXQ-related regression, so it should be safe to re-enable TXQs. > That commit is unrelated to the fq/codel implementations in mac80211, > since mac80211 with txq does not use qdisc. Yup. Which is why it's odd that the initial bug report referred to this; that would indicate that the regression had nothing to do with TXQs in the first place, and we could have merged this ages ago? -Toke
Toke Høiland-Jørgensen wrote: > Commit 4ca1807815aa ("ath10k: disable wake_tx_queue for older devices") > disables the use of the mac80211 TXQs for some devices because of a theoretical > throughput regression. The original regression report[1] was related to > fq_codel qdisc drop performance, which was fixed in commit 9d18562a2278 > ("fq_codel: add batch ability to fq_codel_drop()"). Since then, we have not > seen the TXQ-related regression, so it should be safe to re-enable TXQs. > > [1] http://lists.infradead.org/pipermail/ath10k/2016-April/007266.html > > Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> > Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com> Patch applied to ath-next branch of ath.git, thanks. 170e8e6176d4 ath10k: re-enable TXQs for all devices
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c index 0a947eef348d..ca596ecd2d64 100644 --- a/drivers/net/wireless/ath/ath10k/mac.c +++ b/drivers/net/wireless/ath/ath10k/mac.c @@ -8329,15 +8329,6 @@ int ath10k_mac_register(struct ath10k *ar) ath10k_warn(ar, "failed to initialise DFS pattern detector\n"); } - /* Current wake_tx_queue implementation imposes a significant - * performance penalty in some setups. The tx scheduling code needs - * more work anyway so disable the wake_tx_queue unless firmware - * supports the pull-push mechanism. - */ - if (!test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL, - ar->running_fw->fw_file.fw_features)) - ar->ops->wake_tx_queue = NULL; - ret = ath10k_mac_init_rd(ar); if (ret) { ath10k_err(ar, "failed to derive regdom: %d\n", ret);
Commit 4ca1807815aa6801aaced7fdefa9edacc2521767 disables the use of the mac80211 TXQs for some devices because of a theoretical throughput regression. The original regression report[1] was related to fq_codel qdisc drop performance, which was fixed in 9d18562a227874289fda8ca5d117d8f503f1dcca. Since then, we have not seen the TXQ-related regression, so it should be safe to re-enable TXQs. [1] http://lists.infradead.org/pipermail/ath10k/2016-April/007266.html Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> --- This has been in LEDE trunk for a couple of months now with good results. Changes since v1: - Update commit message to refer to original report and the fix for it. - Add ath10k list to cc drivers/net/wireless/ath/ath10k/mac.c | 9 --------- 1 file changed, 9 deletions(-)