* [PATCH] rtw88: disable TX-AMSDU on 2.4G band
@ 2020-02-04 12:06 yhchuang
2020-02-07 2:21 ` Chris Chiu
2020-02-12 16:22 ` Kalle Valo
0 siblings, 2 replies; 10+ messages in thread
From: yhchuang @ 2020-02-04 12:06 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, briannorris
From: Yan-Hsuan Chuang <yhchuang@realtek.com>
Some tests shows that using AMSDU to aggregate TCP ACKs to specific
APs will degrade the throughput on 2.4G band in 20MHz bandwidth
(< 10 Mbps, should be ~100 Mbps for 2x2). Also found that there's
barely no negative impact if we disable TX AMSDU on 2.4G to connect
to other APs. So it seems like we can just tell mac80211 to not to
aggregate MSDUs when transmitting on 2.4G band.
Note that we still can TX AMSDU on 5G band and benefit from it by
having 50 ~ 70 Mbps throughput improvement.
Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
---
drivers/net/wireless/realtek/rtw88/mac80211.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/mac80211.c b/drivers/net/wireless/realtek/rtw88/mac80211.c
index 6fc33e11d08c..21b56db16916 100644
--- a/drivers/net/wireless/realtek/rtw88/mac80211.c
+++ b/drivers/net/wireless/realtek/rtw88/mac80211.c
@@ -592,6 +592,20 @@ static int rtw_ops_ampdu_action(struct ieee80211_hw *hw,
return 0;
}
+static bool rtw_ops_can_aggregate_in_amsdu(struct ieee80211_hw *hw,
+ struct sk_buff *head,
+ struct sk_buff *skb)
+{
+ struct rtw_dev *rtwdev = hw->priv;
+ struct rtw_hal *hal = &rtwdev->hal;
+
+ /* we don't want to enable TX AMSDU on 2.4G */
+ if (hal->current_band_type == RTW_BAND_2G)
+ return false;
+
+ return true;
+}
+
static void rtw_ops_sw_scan_start(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
const u8 *mac_addr)
@@ -787,6 +801,7 @@ const struct ieee80211_ops rtw_ops = {
.sta_remove = rtw_ops_sta_remove,
.set_key = rtw_ops_set_key,
.ampdu_action = rtw_ops_ampdu_action,
+ .can_aggregate_in_amsdu = rtw_ops_can_aggregate_in_amsdu,
.sw_scan_start = rtw_ops_sw_scan_start,
.sw_scan_complete = rtw_ops_sw_scan_complete,
.mgd_prepare_tx = rtw_ops_mgd_prepare_tx,
--
2.17.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] rtw88: disable TX-AMSDU on 2.4G band
2020-02-04 12:06 [PATCH] rtw88: disable TX-AMSDU on 2.4G band yhchuang
@ 2020-02-07 2:21 ` Chris Chiu
2020-02-07 19:40 ` Justin Capella
2020-02-12 16:22 ` Kalle Valo
1 sibling, 1 reply; 10+ messages in thread
From: Chris Chiu @ 2020-02-07 2:21 UTC (permalink / raw)
To: Tony Chuang; +Cc: Kalle Valo, linux-wireless, Brian Norris
On Tue, Feb 4, 2020 at 8:06 PM <yhchuang@realtek.com> wrote:
>
> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>
> Some tests shows that using AMSDU to aggregate TCP ACKs to specific
> APs will degrade the throughput on 2.4G band in 20MHz bandwidth
> (< 10 Mbps, should be ~100 Mbps for 2x2). Also found that there's
> barely no negative impact if we disable TX AMSDU on 2.4G to connect
> to other APs. So it seems like we can just tell mac80211 to not to
> aggregate MSDUs when transmitting on 2.4G band.
>
> Note that we still can TX AMSDU on 5G band and benefit from it by
> having 50 ~ 70 Mbps throughput improvement.
>
> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
> ---
Reviewed-by: Chris Chiu <chiu@endlessm.com>
> drivers/net/wireless/realtek/rtw88/mac80211.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/mac80211.c b/drivers/net/wireless/realtek/rtw88/mac80211.c
> index 6fc33e11d08c..21b56db16916 100644
> --- a/drivers/net/wireless/realtek/rtw88/mac80211.c
> +++ b/drivers/net/wireless/realtek/rtw88/mac80211.c
> @@ -592,6 +592,20 @@ static int rtw_ops_ampdu_action(struct ieee80211_hw *hw,
> return 0;
> }
>
> +static bool rtw_ops_can_aggregate_in_amsdu(struct ieee80211_hw *hw,
> + struct sk_buff *head,
> + struct sk_buff *skb)
> +{
> + struct rtw_dev *rtwdev = hw->priv;
> + struct rtw_hal *hal = &rtwdev->hal;
> +
> + /* we don't want to enable TX AMSDU on 2.4G */
> + if (hal->current_band_type == RTW_BAND_2G)
> + return false;
> +
> + return true;
> +}
> +
> static void rtw_ops_sw_scan_start(struct ieee80211_hw *hw,
> struct ieee80211_vif *vif,
> const u8 *mac_addr)
> @@ -787,6 +801,7 @@ const struct ieee80211_ops rtw_ops = {
> .sta_remove = rtw_ops_sta_remove,
> .set_key = rtw_ops_set_key,
> .ampdu_action = rtw_ops_ampdu_action,
> + .can_aggregate_in_amsdu = rtw_ops_can_aggregate_in_amsdu,
> .sw_scan_start = rtw_ops_sw_scan_start,
> .sw_scan_complete = rtw_ops_sw_scan_complete,
> .mgd_prepare_tx = rtw_ops_mgd_prepare_tx,
> --
> 2.17.1
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] rtw88: disable TX-AMSDU on 2.4G band
2020-02-07 2:21 ` Chris Chiu
@ 2020-02-07 19:40 ` Justin Capella
2020-02-07 20:41 ` Brian Norris
0 siblings, 1 reply; 10+ messages in thread
From: Justin Capella @ 2020-02-07 19:40 UTC (permalink / raw)
To: Chris Chiu; +Cc: Tony Chuang, Kalle Valo, linux-wireless, Brian Norris
Instead of permanently disabling could a module parameter or other
configurable be used? I appreciate the performance enhancements but
don't like the idea of disabling functionality
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] rtw88: disable TX-AMSDU on 2.4G band
2020-02-07 19:40 ` Justin Capella
@ 2020-02-07 20:41 ` Brian Norris
[not found] ` <CAMrEMU93LScySw4mpidAC5pVHV_NOShP1_GMMsvsAk1QBhdJjQ@mail.gmail.com>
0 siblings, 1 reply; 10+ messages in thread
From: Brian Norris @ 2020-02-07 20:41 UTC (permalink / raw)
To: Justin Capella; +Cc: Chris Chiu, Tony Chuang, Kalle Valo, linux-wireless
On Fri, Feb 7, 2020 at 11:41 AM Justin Capella <justincapella@gmail.com> wrote:
> Instead of permanently disabling could a module parameter or other
> configurable be used? I appreciate the performance enhancements but
> don't like the idea of disabling functionality
It feels like you have that backwards: Tony is claiming that
(a) TX AMSDU does not give any performance benefit on 2.4GHz
(b) TX AMSDU gives a severe performance degradation on 2.4GHz with certain APs
That sounds like a case where the feature should be disabled by
default. (A separate module parameter to re-enable it experimentally
sounds like it could be OK, although it's not likely I would use it or
recommend doing so. But that doesn't sound like what you're
suggesting.)
I say "claiming" above, but I have fielded evidence for (b) at least.
I don't know much about (a), but limited tests haven't showed any real
loss for me.
HTH,
Brian
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] rtw88: disable TX-AMSDU on 2.4G band
2020-02-04 12:06 [PATCH] rtw88: disable TX-AMSDU on 2.4G band yhchuang
2020-02-07 2:21 ` Chris Chiu
@ 2020-02-12 16:22 ` Kalle Valo
1 sibling, 0 replies; 10+ messages in thread
From: Kalle Valo @ 2020-02-12 16:22 UTC (permalink / raw)
To: yhchuang; +Cc: linux-wireless, briannorris
<yhchuang@realtek.com> wrote:
> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>
> Some tests shows that using AMSDU to aggregate TCP ACKs to specific
> APs will degrade the throughput on 2.4G band in 20MHz bandwidth
> (< 10 Mbps, should be ~100 Mbps for 2x2). Also found that there's
> barely no negative impact if we disable TX AMSDU on 2.4G to connect
> to other APs. So it seems like we can just tell mac80211 to not to
> aggregate MSDUs when transmitting on 2.4G band.
>
> Note that we still can TX AMSDU on 5G band and benefit from it by
> having 50 ~ 70 Mbps throughput improvement.
>
> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
> Reviewed-by: Chris Chiu <chiu@endlessm.com>
Patch applied to wireless-drivers-next.git, thanks.
74c3d72cc134 rtw88: disable TX-AMSDU on 2.4G band
--
https://patchwork.kernel.org/patch/11364515/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-03-02 13:44 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-04 12:06 [PATCH] rtw88: disable TX-AMSDU on 2.4G band yhchuang
2020-02-07 2:21 ` Chris Chiu
2020-02-07 19:40 ` Justin Capella
2020-02-07 20:41 ` Brian Norris
[not found] ` <CAMrEMU93LScySw4mpidAC5pVHV_NOShP1_GMMsvsAk1QBhdJjQ@mail.gmail.com>
2020-02-07 20:53 ` Brian Norris
2020-02-08 10:09 ` Kalle Valo
[not found] ` <CAMrEMU-nM1O_iJPVgGg2pL6JYWMdRKdPGe5N2rkfOihdmTeMaw@mail.gmail.com>
2020-02-12 2:55 ` Tony Chuang
2020-02-20 19:04 ` Brian Norris
2020-03-02 13:43 ` Kalle Valo
2020-02-12 16:22 ` Kalle Valo
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.