On 2016-05-16 04:29, Roman Yeryomin wrote:
On 9 May 2016 at 15:26, Michal Kazior <michal.kaz...@tieto.com> wrote:
Hi Roman,
On 22 April 2016 at 19:05, Roman Yeryomin <leroi.li...@gmail.com>
wrote:
On 19 April 2016 at 18:35, Valo, Kalle <kv...@qca.qualcomm.com>
wrote:
Michal Kazior <michal.kaz...@tieto.com> writes:
On 19 April 2016 at 09:31, Roman Yeryomin <leroi.li...@gmail.com>
wrote:
On 19 April 2016 at 08:28, Michal Kazior <michal.kaz...@tieto.com>
wrote:
If my hunch is right there's no easy (and proper) fix for that
now.
One of the patchset patches (ath10k: implement wake_tx_queue)
starts
to use mac80211 software queuing. This introduces extra induced
latency and I'm guessing it results in fill-in-then-drain
sequences in
some cases which end up being long enough to make fq_codel_drop
more
work than normal.
This is required for other changes and MU-MIMO performance
improvements so this patch can't be removed.
But qca988x doesn't support MU-MIMO, AFAIK.
Correct.
Can this be made chip dependent?
I guess it could but it'd arguably make the driver more complex and
harder to maintain. What we want is a long-term fix, not a
short-term
one.
But we should never go backwards and TCP dropping from 750 Mbps to
~550
Mbps is a huge drop, so this is not ok. We have to do something to
fix
this, be it reverting the wake_tx_queue support, somehow disabling
it by
default or something.
I would agree with Kalle here. This looks like very serious
regression.
But I'm afraid I can only help with testing here.
Can you give the following patch a try, please? I didn't get to
reproduce your problem on a real AP135/AP152 board and instead tried
to simulate a slow uni-proc system via KVM and cooling_device in
sysfs. The patch does improve things in this synthetic setup for me.
http://lists.infradead.org/pipermail/ath10k/2016-May/007526.html
Unfortunately doesn't seem to make any difference at all (really, if
there is, it's less than 10Mbps).
Please see this thread also:
https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041445.html
That is with your and Eric's patch applied.
Roman,
Can you please try without registering wake_tx_queue callback? software
queuing is needed for devices that supports peer-flow-control.
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 6829a08638b2..5df904169ded 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7313,7 +7313,6 @@ ath10k_mac_op_switch_vif_chanctx(struct
ieee80211_hw *hw,
static const struct ieee80211_ops ath10k_ops = {
.tx = ath10k_mac_op_tx,
- .wake_tx_queue = ath10k_mac_op_wake_tx_queue,
.start = ath10k_start,
.stop = ath10k_stop,
.config = ath10k_config,
-Rajkumar
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
