From: Chris Chiu <[email protected]>
Since AMPDU_AGGREGATION is set so packets will be handed to the
driver with a flag indicating A-MPDU aggregation and device should
be responsible for setting up and starting the TX aggregation with
the AMPDU_TX_START action. The TX aggregation is usually started by
the rate control algorithm so the HAS_RATE_CONTROL has to be unset
for the mac80211 to start BA session by ieee80211_start_tx_ba_session.
The realtek chips tx rate will still be handled by the rate adaptive
mechanism in the underlying firmware which is controlled by the
rate mask H2C command in the driver. Unset HAS_RATE_CONTROL cause
no change for the tx rate control and the TX BA session can be started
by the mac80211 default rate control mechanism.
Signed-off-by: Chris Chiu <[email protected]>
---
Changelog:
v2:
- Revise the commit message to desribe the purpose of the change
in detail.
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 9ff09cf7eb62..4cf13d2f86b1 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -6678,7 +6678,6 @@ static int rtl8xxxu_probe(struct usb_interface *interface,
/*
* The firmware handles rate control
*/
- ieee80211_hw_set(hw, HAS_RATE_CONTROL);
ieee80211_hw_set(hw, AMPDU_AGGREGATION);
wiphy_ext_feature_set(hw->wiphy, NL80211_EXT_FEATURE_CQM_RSSI_LIST);
--
2.20.1
Hi Chris,
> Since AMPDU_AGGREGATION is set so packets will be handed to the
> driver with a flag indicating A-MPDU aggregation and device should
> be responsible for setting up and starting the TX aggregation with
> the AMPDU_TX_START action. The TX aggregation is usually started by
> the rate control algorithm so the HAS_RATE_CONTROL has to be unset
> for the mac80211 to start BA session by ieee80211_start_tx_ba_session.
>
> The realtek chips tx rate will still be handled by the rate adaptive
> mechanism in the underlying firmware which is controlled by the
> rate mask H2C command in the driver. Unset HAS_RATE_CONTROL cause
> no change for the tx rate control and the TX BA session can be started
> by the mac80211 default rate control mechanism.
This seems ... strange, to say the least? You want to run the full
minstrel algorithm just to have it start aggregation sessions at the
beginning?
I really don't think this makes sense, and it's super confusing. It may
also result in things like reporting a TX rate to userspace/other
components that *minstrel* thinks is the best rate, rather than your
driver's implementation, etc.
I suggest you instead just call ieee80211_start_tx_ba_session() at some
appropriate time, maybe copying parts of the logic of
minstrel_aggr_check().
johannes
On Fri, 2021-06-11 at 22:47 +0800, Chris Chiu wrote:
>
> Based on the description in
> https://github.com/torvalds/linux/blob/master/net/mac80211/agg-tx.c#L32
> to L36, if we set HAS_RATE_CONTROL, which means we don't want the
> software rate control (default minstrel), then we will have to deal
> with both the rate control and the TX aggregation in the driver, and
> the .ampdu_action is not really required.
>
I don't think this is true. You'll probably still want to use the A-MPDU
state machine in mac80211, etc.
What you *don't* get without rate control in mac80211 is any decision on
whether or not to enable A-MPDU, but that's something you can easily do
elsewhere and just call ieee80211_start_tx_ba_session() at an
appropriate point in time.
johannes