[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4e2a1fc1-4c14-733d-74e2-750ef1f81bf6@infradead.org>
Date: Tue, 3 Mar 2020 20:05:53 -0800
From: Randy Dunlap <rdunlap@...radead.org>
To: "Mancini, Jason" <Jason.Mancini@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Yan-Hsuan Chuang <yhchuang@...ltek.com>,
Kalle Valo <kvalo@...eaurora.org>
Subject: Re: v5.5-rc1 and beyond insta-kills some Comcast wifi routers
[add netdev mailing list + 2 patch signers]
On 3/3/20 7:34 PM, Mancini, Jason wrote:
> [I can't seem to access the linux-net ml per kernel.org faq, apology
> in advance.]
>
> This change, which I think first appeared for v5.5-rc1, basically
> within seconds, knocks out our [apparently buggy] Comcast wifi for
> about 2-3 minutes. Is there a boot option (or similar) where I can
> achieve prior kernel behavior? Otherwise I am stuck on kernel 5.4
> (or Win10) it seems, or forever compiling custom kernels for my
> choice of distribution [as I don't have physical access to the router
> in question.]
> Thanks!
> Jason
>
> ================
>
> 127eef1d46f80056fe9f18406c6eab38778d8a06 is the first bad commit
> commit 127eef1d46f80056fe9f18406c6eab38778d8a06
> Author: Yan-Hsuan Chuang <yhchuang@...ltek.com>
> Date: Wed Oct 2 14:35:23 2019 +0800
>
> rtw88: add TX-AMSDU support
>
> Based on the mac80211's TXQ implementation, TX-AMSDU can
> be used to get higher MAC efficiency. To make mac80211
> aggregate MSDUs, low level driver just need to leave skbs
> in the TXQ, and mac80211 will try to aggregate them if
> possible. As driver will schedule a tasklet when the TX
> queue is woke, until the tasklet being served, there will
> have some skbs in the queue if traffic is heavy.
>
> Driver can control the max AMSDU size depending on the
> current bit rate used by hardware/firmware. The higher
> rates are used, the larger AMSDU size can be.
>
> It is tested that can achieve higher T-Put at higher rates.
> If the environment is relatively clean, and the bit_rate
> is high enough, we can get about 80Mbps improvement.
>
> For lower bit rates, not much gain can we get, so leave
> the max_amsdu length low to prevent aggregation.
>
> Signed-off-by: Yan-Hsuan Chuang <yhchuang@...ltek.com>
> Signed-off-by: Kalle Valo <kvalo@...eaurora.org>
>
> drivers/net/wireless/realtek/rtw88/fw.c | 24 ++++++++++++++++++++++++
> drivers/net/wireless/realtek/rtw88/main.c | 1 +
> 2 files changed, 25 insertions(+)
>
> ------------------- drivers/net/wireless/realtek/rtw88/fw.c -------------------
> index 4b41bf531998..51649df7cc98 100644
> @@ -29,6 +29,28 @@ static void rtw_fw_c2h_cmd_handle_ext(struct rtw_dev *rtwdev,
> }
> }
>
> +static u16 get_max_amsdu_len(u32 bit_rate)
> +{
> + /* lower than ofdm, do not aggregate */
> + if (bit_rate < 550)
> + return 1;
> +
> + /* lower than 20M 2ss mcs8, make it small */
> + if (bit_rate < 1800)
> + return 1200;
> +
> + /* lower than 40M 2ss mcs9, make it medium */
> + if (bit_rate < 4000)
> + return 2600;
> +
> + /* not yet 80M 2ss mcs8/9, make it twice regular packet size */
> + if (bit_rate < 7000)
> + return 3500;
> +
> + /* unlimited */
> + return 0;
> +}
> +
> struct rtw_fw_iter_ra_data {
> struct rtw_dev *rtwdev;
> u8 *payload;
> @@ -83,6 +105,8 @@ static void rtw_fw_ra_report_iter(void *data, struct ieee80211_sta *sta)
>
> si->ra_report.desc_rate = rate;
> si->ra_report.bit_rate = bit_rate;
> +
> + sta->max_rc_amsdu_len = get_max_amsdu_len(bit_rate);
> }
>
> static void rtw_fw_ra_report_handle(struct rtw_dev *rtwdev, u8 *payload,
>
> ------------------ drivers/net/wireless/realtek/rtw88/main.c ------------------
> index 690a5c4d64e7..f7044e8bcb5b 100644
> @@ -1310,6 +1310,7 @@ int rtw_register_hw(struct rtw_dev *rtwdev, struct ieee80211_hw *hw)
> ieee80211_hw_set(hw, SUPPORT_FAST_XMIT);
> ieee80211_hw_set(hw, SUPPORTS_AMSDU_IN_AMPDU);
> ieee80211_hw_set(hw, HAS_RATE_CONTROL);
> + ieee80211_hw_set(hw, TX_AMSDU);
>
> hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
> BIT(NL80211_IFTYPE_AP) |
>
--
~Randy
Reported-by: Randy Dunlap <rdunlap@...radead.org>
Powered by blists - more mailing lists