On 2019-03-11 14:44, Erik Stromdahl wrote:
Hi Yibo,
Sorry for a late reply, but I have been busy with other projects
lately.
I have added my comments below
On 3/4/19 2:56 AM, Yibo Zhao wrote:
在 2019-02-25 12:40，Yibo Zhao 写道：
在 2019-02-07 22:25，Kalle Valo 写道：
Yibo Zhao <yiboz@xxxxxxxxxxxxxx> writes:
I have a few patches related to bundling of TX packets on my private
repo.
I have not yet had the time to prepare them for submission.
This patch is related to that work, but I decided to submit it
separately
since I considered it a bugfix.
Great! Really looking forward to your new patch.
<snip>
IMHO, with Erik's change, Erik's change has changed the way fq's
schedule behavior and it looks like there is no other packets in the
fq after a packet has been dequeued. And as a result, this flow's
deficit will be refill and then removed from fq list at once in the
same CPU. And during this time, the other CPU could be blocked. When
new packet comes, same thing happens. So we get equal new flows and
tx-packets.
Things would be different without Erik's change. After a packet has
been dequeued, this flow's deficit will not be refill immediately in
CPU0. It is possible that the deficit to be refilled in CPU1 while at
the same time CPU0 can fetch data from ethernet. So we can see more
tx-packets delivered to FW from aqm.
Why does this happen only WDS mode? Did you test other modes, like
AP or
client mode?
AP mode has same issue. UDP throughput drops more than 10%. As for
TCP, CPU usage rising a lot although throughput stays similiar.
So, I'd say Erik's change does not work for us.
Hi Kalle,
May I have your comments?
As I wrote in the commit message, the original code will always break
out of
the loop after just one iteration.
It is OK with me to bring back the old logic, but I think we should
skip the
loop entirely then.
Something like this:
if (ath10k_mac_tx_can_push(hw, txq)) {
ath10k_mac_tx_push_txq(hw, txq);
}
Yes, it is the exact way we tried in our private repo. And it works fine
in our setup so far. Not sure it is ok for other situations. Have you
tested on your sdio setup with this change? Any issue observed?
Btw, I noticed that the "fair scheduling" mechanism (derived from
ath9k) from
Toke have been integrated.
I haven't rebased my tree for a while, so I will most likely have to
rewrite
my patches anyway in order to make them work with the new TX
scheduling.
--
Yibo
