Dmitry Osipenko 於 8/5/2020 10:01 PM 寫道:
05.08.2020 11:24, Chi-Hsien Lin пишет:
On 8/5/2020 1:22 AM, Kalle Valo wrote:
Dmitry Osipenko <digetx@xxxxxxxxx> writes:
04.08.2020 14:08, Kalle Valo пишет:
Dmitry Osipenko <digetx@xxxxxxxxx> writes:
10.06.2020 18:21, Chi-Hsien Lin пишет:
From: Amar Shankar <amsr@xxxxxxxxxxx>
It is observed that sometimes when sdiod is low in tx credits in low
rssi scenarios, the data path consumes all sdiod rx all credits and
there is no sdiod rx credit available for control path causing host
and card to go out of sync resulting in link loss between host and
card. So in order to prevent it some credits are reserved for control
path.
Note that TXCTL_CREDITS can't be larger than the firmware default
credit update threshold 2; otherwise there will be a deadlock for
both
side waiting for each other.
Signed-off-by: Amar Shankar <amsr@xxxxxxxxxxx>
Signed-off-by: Jia-Shyr Chuang <joseph.chuang@xxxxxxxxxxx>
Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@xxxxxxxxxxx>
[...]
This patch causes a severe WiFi performance regression on BCM4329.
Please fix or revert this patch, thanks in advance.
Before this patch:
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 17.2 MBytes 14.4 Mbits/sec
0 sender
[ 5] 0.00-10.04 sec 16.9 MBytes 14.1 Mbits/sec
receiver
After this patch:
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.05 MBytes 881 Kbits/sec
3 sender
[ 5] 0.00-14.01 sec 959 KBytes 561 Kbits/sec
receiver
Can someone please send a revert patch (with the explanation above)
if a
fix is not quickly found? The commit id is:
commit b41c232d33666191a1db11befc0f040fcbe664e9
Author: Amar Shankar <amsr@xxxxxxxxxxx>
AuthorDate: Wed Jun 10 10:21:03 2020 -0500
Commit: Kalle Valo <kvalo@xxxxxxxxxxxxxx>
CommitDate: Tue Jul 14 12:46:43 2020 +0300
brcmfmac: reserve 2 credits for host tx control path
Hello Kalle,
I'll send the revert if nobody will stand up to address the problem in a
two weeks, thanks.
Thanks. Then I should be able to get the revert to v5.9 so that the
release won't be broken. (v5.8 is unaffected)
Dmitry/Kalle,
We'll take a look and revert/fix it in a few days.
Good to know, thank you.
Hi Dmitry,
We have a fix for this issue. But we got the different test result
numbers from yours, so would you help us verify the same with
following patch in your setup?
With your confirmation, I can make sure we see the same issue.
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index e8712ad3ac45..ea07bb1bfe27 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -664,8 +664,13 @@ static void pkt_align(struct sk_buff *p, int len,
int align)
/* To check if there's window offered */
static bool data_ok(struct brcmf_sdio *bus)
{
- /* Reserve TXCTL_CREDITS credits for txctl */
- return (bus->tx_max - bus->tx_seq) > TXCTL_CREDITS &&
+ u8 tx_rsv = 0;
+
+ /* Reserve TXCTL_CREDITS credits for txctl when it is ready to send */
+ if (bus->ctrl_frame_stat)
+ tx_rsv = TXCTL_CREDITS;
+
+ return (bus->tx_max - bus->tx_seq) > tx_rsv &&
((bus->tx_max - bus->tx_seq) & 0x80) == 0;
}
--
Here is our 4329 TX throughput result.
Without the fix:
Interval Transfer Bandwidth Retr
0.00-10.00 sec 36.4 MBytes 30.6 Mbits/sec receiver
With the fix:
Interval Transfer Bandwidth Retr
0.00-10.00 sec 47.9 MBytes 40.2 Mbits/sec receiver
