2012-04-16 23:07:25

by Andreas Hartmann

Subject: [PATCH] rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails

There are connection stalls or very poor throughputs with rt2800
hardware using 802.11n in AP mode since patch "mac80211: retry sending
failed BAR frames later instead of tearing down aggr"[1][2].

Since rt2800 hardware is not able to correctly report the tx status of
BAR frames, this patch removes as workaround the existing error handling
on AP side, which lets mac80211 send a BAR when an AMPDU subframe fails.

As a result, most wifi clients (aside from Intel STAs on Windows)
instead will timeout now the reorder buffer and request the lost frame
again.

The correct solution would be, to tear down BA session on AP side.

This patch was born on the basis of "[RFT] rt2x00: Tear down BA
session on QoS frame failure"[3].

Thanks to Helmut Schaa for his support!

[1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
[2] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=f0425beda4d404a6e751439b562100b902ba9c98
[3] http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/569

Signed-off-by: Andreas Hartmann <[email protected]>
---
Index: a/drivers/net/wireless/rt2x00/rt2x00dev.c
===================================================================================
--- a/drivers/net/wireless/rt2x00/rt2x00dev.c 2012-02-02 22:12:56.000000000 +0100
+++ b/drivers/net/wireless/rt2x00/rt2x00dev.c 2012-04-16 23:26:46.100458775 +0200
@@ -387,9 +387,10 @@
tx_info->flags |= IEEE80211_TX_STAT_AMPDU;
tx_info->status.ampdu_len = 1;
tx_info->status.ampdu_ack_len = success ? 1 : 0;
-
- if (!success)
- tx_info->flags |= IEEE80211_TX_STAT_AMPDU_NO_BACK;
+ /*
+ * TODO: Need to tear down BA session here
+ * if not successful.
+ */
}

if (rate_flags & IEEE80211_TX_RC_USE_RTS_CTS) {

2012-04-17 08:09:00

by Helmut Schaa

Subject: Re: [PATCH] rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails

On Tue, Apr 17, 2012 at 12:25 AM, Andreas Hartmann
<[email protected]> wrote:
> There are connection stalls or very poor throughputs with rt2800
> hardware using 802.11n in AP mode since patch "mac80211: retry sending
> failed BAR frames later instead of tearing down aggr"[1][2].
>
> Since rt2800 hardware is not able to correctly report the tx status of
> BAR frames, this patch removes as workaround the existing error handling
> on AP side, which lets mac80211 send a BAR when an AMPDU subframe fails.
>
> As a result, most wifi clients (aside from Intel STAs on Windows)
> instead will timeout now the reorder buffer and request the lost frame
> again.
>
> The correct solution would be, to tear down BA session on AP side.
>
> This patch was born on the basis of "[RFT] rt2x00: Tear down BA
> session on QoS frame failure"[3].
>
> Thanks to Helmut Schaa for his support!
>
> [1] http://thread.gmane.org/gmane.linux.kernel.wireless.general/83297/focus=83304
> [2] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=f0425beda4d404a6e751439b562100b902ba9c98
> [3] http://thread.gmane.org/gmane.linux.drivers.rt2x00.user/569
>
> Signed-off-by: Andreas Hartmann <[email protected]>

Thanks for the patch Andreas! Let's use this as a workaround for now.

Acked-by: Helmut Schaa <[email protected]>

> ---
> Index: a/drivers/net/wireless/rt2x00/rt2x00dev.c
> ===================================================================================
> --- a/drivers/net/wireless/rt2x00/rt2x00dev.c ? 2012-02-02 22:12:56.000000000 +0100
> +++ b/drivers/net/wireless/rt2x00/rt2x00dev.c ? 2012-04-16 23:26:46.100458775 +0200
> @@ -387,9 +387,10 @@
> ? ? ? ? ? ? ? ?tx_info->flags |= IEEE80211_TX_STAT_AMPDU;
> ? ? ? ? ? ? ? ?tx_info->status.ampdu_len = 1;
> ? ? ? ? ? ? ? ?tx_info->status.ampdu_ack_len = success ? 1 : 0;
> -
> - ? ? ? ? ? ? ? if (!success)
> - ? ? ? ? ? ? ? ? ? ? ? tx_info->flags |= IEEE80211_TX_STAT_AMPDU_NO_BACK;
> + ? ? ? ? ? ? ? /*
> + ? ? ? ? ? ? ? ?* TODO: Need to tear down BA session here
> + ? ? ? ? ? ? ? ?* if not successful.
> + ? ? ? ? ? ? ? ?*/
> ? ? ? ?}
>
> ? ? ? ?if (rate_flags & IEEE80211_TX_RC_USE_RTS_CTS) {