On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach
<emmanuel.grumbach@xxxxxxxxx> wrote:
> index 7a76ce6..f4a5287 100644
> --- a/net/mac80211/ht.c
> +++ b/net/mac80211/ht.c
> @@ -230,6 +230,11 @@ bool ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_sub_if_data *sdata,
> /* set Rx highest rate */
> ht_cap.mcs.rx_highest = ht_cap_ie->mcs.rx_highest;
>
> + if (ht_cap.cap & IEEE80211_HT_CAP_MAX_AMSDU)
> + sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_HT_7935;
> + else
> + sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_HT_3839;
> +
> apply:
> changed = memcmp(&sta->sta.ht_cap, &ht_cap, sizeof(ht_cap));
>
> diff --git a/net/mac80211/vht.c b/net/mac80211/vht.c
> index 92c9843..d2f2ff6 100644
> --- a/net/mac80211/vht.c
> +++ b/net/mac80211/vht.c
> @@ -281,6 +281,24 @@ ieee80211_vht_cap_ie_to_sta_vht_cap(struct ieee80211_sub_if_data *sdata,
> }
>
> sta->sta.bandwidth = ieee80211_sta_cur_vht_bw(sta);
> +
> + /* If HT IE reported 3839 bytes only, stay with that size. */
> + if (sta->sta.max_amsdu_len == IEEE80211_MAX_MPDU_LEN_HT_3839)
> + return;
> +
> + switch (vht_cap->cap & IEEE80211_VHT_CAP_MAX_MPDU_MASK) {
> + case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_11454:
> + sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_11454;
> + break;
> + case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_7991:
> + sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_7991;
> + break;
> + case IEEE80211_VHT_CAP_MAX_MPDU_LENGTH_3895:
> + default:
> + sta->sta.max_amsdu_len = IEEE80211_MAX_MPDU_LEN_VHT_3895;
> + break;
> + }
Ideally speaking shouldn't we use different variables for HT and VHT
and depending on
rate HT/VHT we should aggregate accordingly? of course that will be
tricky as we dont
have the rate control info at the time of aggregation. Standard is
clear about usage of
independent lengths depending on whether its an VHT/HT PPDU.
If we use the same variable to arrive at max_amsdu_len for both VHT
and HT, we might
end up sending 11454 sized MSDU in a HT rate.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
