Re: [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
Chris Chiu writes: > On Mon, Aug 12, 2019 at 11:21 PM Jes Sorensen wrote: >> >> On 8/12/19 10:32 AM, Kalle Valo wrote: >> >> Signed-off-by: Jes Sorensen >> > >> > This is marked as RFC so I'm not sure what's the plan. Should I apply >> > this? >> >> I think it's at a point where it's worth applying - I kinda wish I had >> had time to test it, but I won't be near my stash of USB dongles for a >> little while. >> >> Cheers, >> Jes >> > > Gentle ping. Any suggestions for the next step? Please resubmit without the RFC label. -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
On Mon, Aug 12, 2019 at 11:21 PM Jes Sorensen wrote: > > On 8/12/19 10:32 AM, Kalle Valo wrote: > >> Signed-off-by: Jes Sorensen > > > > This is marked as RFC so I'm not sure what's the plan. Should I apply > > this? > > I think it's at a point where it's worth applying - I kinda wish I had > had time to test it, but I won't be near my stash of USB dongles for a > little while. > > Cheers, > Jes > Gentle ping. Any suggestions for the next step? Chris
Re: [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
On Mon, Aug 12, 2019 at 11:21 PM Jes Sorensen wrote: > On 8/12/19 10:32 AM, Kalle Valo wrote: > > This is marked as RFC so I'm not sure what's the plan. Should I apply > > this? > > I think it's at a point where it's worth applying - I kinda wish I had > had time to test it, but I won't be near my stash of USB dongles for a > little while. The last remaining reason it was RFC was pending feedback from Jes, to check that his earlier comments had been adequately addressed. So yes I think it's good to apply now. Thanks, Daniel
Re: [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
On 8/12/19 10:32 AM, Kalle Valo wrote: > Jes Sorensen writes: >> Looks good to me! Nice work! I am actually very curious if this will >> improve performance 8192eu as well. >> >> Ideally I'd like to figure out how to make host controlled rates work, >> but in all my experiments with that, I never really got it to work well. >> >> Signed-off-by: Jes Sorensen > > This is marked as RFC so I'm not sure what's the plan. Should I apply > this? I think it's at a point where it's worth applying - I kinda wish I had had time to test it, but I won't be near my stash of USB dongles for a little while. Cheers, Jes
Re: [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
Jes Sorensen writes: > On 8/5/19 9:14 AM, Chris Chiu wrote: >> We have 3 laptops which connect the wifi by the same RTL8723BU. >> The PCI VID/PID of the wifi chip is 10EC:B720 which is supported. >> They have the same problem with the in-kernel rtl8xxxu driver, the >> iperf (as a client to an ethernet-connected server) gets ~1Mbps. >> Nevertheless, the signal strength is reported as around -40dBm, >> which is quite good. From the wireshark capture, the tx rate for each >> data and qos data packet is only 1Mbps. Compare to the Realtek driver >> at https://github.com/lwfinger/rtl8723bu, the same iperf test gets >> ~12Mbps or better. The signal strength is reported similarly around >> -40dBm. That's why we want to improve. >> >> After reading the source code of the rtl8xxxu driver and Realtek's, the >> major difference is that Realtek's driver has a watchdog which will keep >> monitoring the signal quality and updating the rate mask just like the >> rtl8xxxu_gen2_update_rate_mask() does if signal quality changes. >> And this kind of watchdog also exists in rtlwifi driver of some specific >> chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have >> the same member function named dm_watchdog and will invoke the >> corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate >> mask. >> >> With this commit, the tx rate of each data and qos data packet will >> be 39Mbps (MCS4) with the 0xF0 as the tx rate mask. The 20th bit >> to 23th bit means MCS4 to MCS7. It means that the firmware still picks >> the lowest rate from the rate mask and explains why the tx rate of >> data and qos data is always lowest 1Mbps because the default rate mask >> passed is always 0xFFF ranges from the basic CCK rate, OFDM rate, >> and MCS rate. However, with Realtek's driver, the tx rate observed from >> wireshark under the same condition is almost 65Mbps or 72Mbps, which >> indicating that rtl8xxxu could still be further improved. >> >> Signed-off-by: Chris Chiu >> Reviewed-by: Daniel Drake >> --- > > Looks good to me! Nice work! I am actually very curious if this will > improve performance 8192eu as well. > > Ideally I'd like to figure out how to make host controlled rates work, > but in all my experiments with that, I never really got it to work well. > > Signed-off-by: Jes Sorensen This is marked as RFC so I'm not sure what's the plan. Should I apply this? -- https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
On 8/5/19 9:14 AM, Chris Chiu wrote:
> We have 3 laptops which connect the wifi by the same RTL8723BU.
> The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
> They have the same problem with the in-kernel rtl8xxxu driver, the
> iperf (as a client to an ethernet-connected server) gets ~1Mbps.
> Nevertheless, the signal strength is reported as around -40dBm,
> which is quite good. From the wireshark capture, the tx rate for each
> data and qos data packet is only 1Mbps. Compare to the Realtek driver
> at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
> ~12Mbps or better. The signal strength is reported similarly around
> -40dBm. That's why we want to improve.
>
> After reading the source code of the rtl8xxxu driver and Realtek's, the
> major difference is that Realtek's driver has a watchdog which will keep
> monitoring the signal quality and updating the rate mask just like the
> rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
> And this kind of watchdog also exists in rtlwifi driver of some specific
> chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
> the same member function named dm_watchdog and will invoke the
> corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
> mask.
>
> With this commit, the tx rate of each data and qos data packet will
> be 39Mbps (MCS4) with the 0xF0 as the tx rate mask. The 20th bit
> to 23th bit means MCS4 to MCS7. It means that the firmware still picks
> the lowest rate from the rate mask and explains why the tx rate of
> data and qos data is always lowest 1Mbps because the default rate mask
> passed is always 0xFFF ranges from the basic CCK rate, OFDM rate,
> and MCS rate. However, with Realtek's driver, the tx rate observed from
> wireshark under the same condition is almost 65Mbps or 72Mbps, which
> indicating that rtl8xxxu could still be further improved.
>
> Signed-off-by: Chris Chiu
> Reviewed-by: Daniel Drake
> ---
Looks good to me! Nice work! I am actually very curious if this will
improve performance 8192eu as well.
Ideally I'd like to figure out how to make host controlled rates work,
but in all my experiments with that, I never really got it to work well.
Signed-off-by: Jes Sorensen
Jes
>
> Notes:
> v2:
>- Fix errors and warnings complained by checkpatch.pl
>- Replace data structure rate_adaptive by 2 member variables
>- Make rtl8xxxu_wireless_mode non-static
>- Runs refresh_rate_mask() only in station mode
> v3:
>- Remove ugly rtl8xxxu_watchdog data structure
>- Make sure only one vif exists
> v4:
>- Move cancel_delayed_work from rtl8xxxu_disconnect to rtl8xxxu_stop
>- Clear priv->vif in rtl8xxxu_remove_interface
>- Add rateid as the function argument of update_rate_mask
>- Rephrase the comment for priv->vif more explicit.
> v5:
>- Make refresh_rate_mask() generic for all sub-drivers.
>- Add definitions for SNR related to help determine rssi_level
> v6:
>- Fix typo of the comment for priv->vif
> v7:
>- Fix reported bug of watchdog stop
>- refer to the RxPWDBAll in vendor driver for SNR calculation
>
>
> .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 55 -
> .../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 229 +-
> 2 files changed, 277 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> index ade057d868f7..582c2a346cec 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> @@ -1187,6 +1187,48 @@ struct rtl8723bu_c2h {
>
> struct rtl8xxxu_fileops;
>
> +/*mlme related.*/
> +enum wireless_mode {
> + WIRELESS_MODE_UNKNOWN = 0,
> + /* Sub-Element */
> + WIRELESS_MODE_B = BIT(0),
> + WIRELESS_MODE_G = BIT(1),
> + WIRELESS_MODE_A = BIT(2),
> + WIRELESS_MODE_N_24G = BIT(3),
> + WIRELESS_MODE_N_5G = BIT(4),
> + WIRELESS_AUTO = BIT(5),
> + WIRELESS_MODE_AC = BIT(6),
> + WIRELESS_MODE_MAX = 0x7F,
> +};
> +
> +/* from rtlwifi/wifi.h */
> +enum ratr_table_mode_new {
> + RATEID_IDX_BGN_40M_2SS = 0,
> + RATEID_IDX_BGN_40M_1SS = 1,
> + RATEID_IDX_BGN_20M_2SS_BN = 2,
> + RATEID_IDX_BGN_20M_1SS_BN = 3,
> + RATEID_IDX_GN_N2SS = 4,
> + RATEID_IDX_GN_N1SS = 5,
> + RATEID_IDX_BG = 6,
> + RATEID_IDX_G = 7,
> + RATEID_IDX_B = 8,
> + RATEID_IDX_VHT_2SS = 9,
> + RATEID_IDX_VHT_1SS = 10,
> + RATEID_IDX_MIX1 = 11,
> + RATEID_IDX_MIX2 = 12,
> + RATEID_IDX_VHT_3SS = 13,
> + RATEID_IDX_BGN_3SS = 14,
> +};
> +
> +#define RTL8XXXU_RATR_STA_INIT 0
> +#define RTL8XXXU_RATR_STA_HIGH 1
> +#define RTL8XXXU_RATR_STA_MID 2
> +#define RTL8XXXU_RATR_STA_LOW 3
> +
> +#define RTL8XXXU_NOISE_FLOOR_MIN -100
> +#define RTL8XXXU_SNR_THRESH_HIGH 50
> +#define RTL8XXXU_SNR_THRESH_LOW 20
> +
> struct rtl8xxxu_priv {
> struct
Re: [RFC PATCH v7] rtl8xxxu: Improve TX performance of RTL8723BU on rtl8xxxu driver
On Mon, Aug 5, 2019 at 9:15 PM Chris Chiu wrote:
>
> We have 3 laptops which connect the wifi by the same RTL8723BU.
> The PCI VID/PID of the wifi chip is 10EC:B720 which is supported.
> They have the same problem with the in-kernel rtl8xxxu driver, the
> iperf (as a client to an ethernet-connected server) gets ~1Mbps.
> Nevertheless, the signal strength is reported as around -40dBm,
> which is quite good. From the wireshark capture, the tx rate for each
> data and qos data packet is only 1Mbps. Compare to the Realtek driver
> at https://github.com/lwfinger/rtl8723bu, the same iperf test gets
> ~12Mbps or better. The signal strength is reported similarly around
> -40dBm. That's why we want to improve.
>
> After reading the source code of the rtl8xxxu driver and Realtek's, the
> major difference is that Realtek's driver has a watchdog which will keep
> monitoring the signal quality and updating the rate mask just like the
> rtl8xxxu_gen2_update_rate_mask() does if signal quality changes.
> And this kind of watchdog also exists in rtlwifi driver of some specific
> chips, ex rtl8192ee, rtl8188ee, rtl8723ae, rtl8821ae...etc. They have
> the same member function named dm_watchdog and will invoke the
> corresponding dm_refresh_rate_adaptive_mask to adjust the tx rate
> mask.
>
> With this commit, the tx rate of each data and qos data packet will
> be 39Mbps (MCS4) with the 0xF0 as the tx rate mask. The 20th bit
> to 23th bit means MCS4 to MCS7. It means that the firmware still picks
> the lowest rate from the rate mask and explains why the tx rate of
> data and qos data is always lowest 1Mbps because the default rate mask
> passed is always 0xFFF ranges from the basic CCK rate, OFDM rate,
> and MCS rate. However, with Realtek's driver, the tx rate observed from
> wireshark under the same condition is almost 65Mbps or 72Mbps, which
> indicating that rtl8xxxu could still be further improved.
>
> Signed-off-by: Chris Chiu
> Reviewed-by: Daniel Drake
Tested-by: Kleintje Jens
> ---
>
>
> Notes:
> v2:
>- Fix errors and warnings complained by checkpatch.pl
>- Replace data structure rate_adaptive by 2 member variables
>- Make rtl8xxxu_wireless_mode non-static
>- Runs refresh_rate_mask() only in station mode
> v3:
>- Remove ugly rtl8xxxu_watchdog data structure
>- Make sure only one vif exists
> v4:
>- Move cancel_delayed_work from rtl8xxxu_disconnect to rtl8xxxu_stop
>- Clear priv->vif in rtl8xxxu_remove_interface
>- Add rateid as the function argument of update_rate_mask
>- Rephrase the comment for priv->vif more explicit.
> v5:
>- Make refresh_rate_mask() generic for all sub-drivers.
>- Add definitions for SNR related to help determine rssi_level
> v6:
>- Fix typo of the comment for priv->vif
> v7:
>- Fix reported bug of watchdog stop
>- refer to the RxPWDBAll in vendor driver for SNR calculation
>
>
> .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h | 55 -
> .../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 229 +-
> 2 files changed, 277 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> index ade057d868f7..582c2a346cec 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
> @@ -1187,6 +1187,48 @@ struct rtl8723bu_c2h {
>
> struct rtl8xxxu_fileops;
>
> +/*mlme related.*/
> +enum wireless_mode {
> + WIRELESS_MODE_UNKNOWN = 0,
> + /* Sub-Element */
> + WIRELESS_MODE_B = BIT(0),
> + WIRELESS_MODE_G = BIT(1),
> + WIRELESS_MODE_A = BIT(2),
> + WIRELESS_MODE_N_24G = BIT(3),
> + WIRELESS_MODE_N_5G = BIT(4),
> + WIRELESS_AUTO = BIT(5),
> + WIRELESS_MODE_AC = BIT(6),
> + WIRELESS_MODE_MAX = 0x7F,
> +};
> +
> +/* from rtlwifi/wifi.h */
> +enum ratr_table_mode_new {
> + RATEID_IDX_BGN_40M_2SS = 0,
> + RATEID_IDX_BGN_40M_1SS = 1,
> + RATEID_IDX_BGN_20M_2SS_BN = 2,
> + RATEID_IDX_BGN_20M_1SS_BN = 3,
> + RATEID_IDX_GN_N2SS = 4,
> + RATEID_IDX_GN_N1SS = 5,
> + RATEID_IDX_BG = 6,
> + RATEID_IDX_G = 7,
> + RATEID_IDX_B = 8,
> + RATEID_IDX_VHT_2SS = 9,
> + RATEID_IDX_VHT_1SS = 10,
> + RATEID_IDX_MIX1 = 11,
> + RATEID_IDX_MIX2 = 12,
> + RATEID_IDX_VHT_3SS = 13,
> + RATEID_IDX_BGN_3SS = 14,
> +};
> +
> +#define RTL8XXXU_RATR_STA_INIT 0
> +#define RTL8XXXU_RATR_STA_HIGH 1
> +#define RTL8XXXU_RATR_STA_MID 2
> +#define RTL8XXXU_RATR_STA_LOW 3
> +
> +#define RTL8XXXU_NOISE_FLOOR_MIN -100
> +#define RTL8XXXU_SNR_THRESH_HIGH 50
> +#define RTL8XXXU_SNR_THRESH_LOW20
> +
> struct rtl8xxxu_priv {
> struct ieee80211_hw *hw;
> struct usb_device *udev;
> @@ -1291,6 +1333,13 @@ struct rtl8xxxu_priv {
> u8 pi_enabled:1;
> u8 no_pape:1;
> u8 int_buf[USB_INTR_CONTENT_LENGTH];
>
