On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach <[email protected]> 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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
