On 12/08/2015 06:03 PM, Krishna Chaitanya wrote: > On Tue, Dec 8, 2015 at 7:34 PM, Emmanuel Grumbach > <emmanuel.grumb...@intel.com> 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.
Yes - but since it is tricky, I preferred to be on the safe side and limit VHT amsdus for the very peculiar AP that would decide to have large A-MSDUs in VHT and small ones in HT (?!). > 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. > And since that can't be handled at the time of the A-MSDU building, leave that to another entity :) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html