Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: v5.5-rc1 and beyond insta-kills some Comcast wifi routers
To:     "Mancini, Jason" <Jason.Mancini@amd.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        Yan-Hsuan Chuang <yhchuang@realtek.com>,
        Kalle Valo <kvalo@codeaurora.org>
References: <DM6PR12MB4331FD3C4EF86E6AF2B3EBC7E5E50@DM6PR12MB4331.namprd12.prod.outlook.com>
From:   Randy Dunlap <rdunlap@infradead.org>
Message-ID: <4e2a1fc1-4c14-733d-74e2-750ef1f81bf6@infradead.org>
Date:   Tue, 3 Mar 2020 20:05:53 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <DM6PR12MB4331FD3C4EF86E6AF2B3EBC7E5E50@DM6PR12MB4331.namprd12.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

[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@realtek.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@realtek.com>
>     Signed-off-by: Kalle Valo <kvalo@codeaurora.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@infradead.org>