| Message ID | 1415079413-3048-6-git-send-email-masashi.honma@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
On Tue, Nov 04, 2014 at 02:36:47PM +0900, Masashi Honma wrote: > +#ifdef CONFIG_IEEE80211N > + if (type != PLINK_CLOSE && > + wpa_s->current_ssid->mesh_ht_mode > CHAN_NO_HT) { > + buf_len += 2 + 26 + /* HT capabilities */ > + 2 + 22; /* HT operation */ > + } > +#endif /* CONFIG_IEEE80211N */ Hmm, does it really matter if you allocate an extra 52 bytes?
2014-11-04 21:02 GMT+09:00 Bob Copeland <me@bobcopeland.com>: > Hmm, does it really matter if you allocate an extra 52 bytes? I was not reported it causes any problem. This is just refactoring. 2014-11-04 21:02 GMT+09:00 Bob Copeland <me@bobcopeland.com>: > On Tue, Nov 04, 2014 at 02:36:47PM +0900, Masashi Honma wrote: >> +#ifdef CONFIG_IEEE80211N >> + if (type != PLINK_CLOSE && >> + wpa_s->current_ssid->mesh_ht_mode > CHAN_NO_HT) { >> + buf_len += 2 + 26 + /* HT capabilities */ >> + 2 + 22; /* HT operation */ >> + } >> +#endif /* CONFIG_IEEE80211N */ > > Hmm, does it really matter if you allocate an extra 52 bytes? > > -- > Bob Copeland %% www.bobcopeland.com
On Tue, Nov 04, 2014 at 10:54:36PM +0900, Masashi Honma wrote: > 2014-11-04 21:02 GMT+09:00 Bob Copeland <me@bobcopeland.com>: > > Hmm, does it really matter if you allocate an extra 52 bytes? > > I was not reported it causes any problem. > > This is just refactoring. Ok, I see now, I was confused by the subject which said it reduced frame size, when it's really changing the size of an allocation. I think this was in an earlier patch but I left it out to reduce #ifdef clutter -- but it doesn't matter too much to me either way.
2014-11-04 23:00 GMT+09:00 Bob Copeland <me@bobcopeland.com>: > I was confused by the subject which said it reduced frame size. Right. I should change my commit log. This patch only reduces allocation size. 2014-11-04 23:00 GMT+09:00 Bob Copeland <me@bobcopeland.com>: > On Tue, Nov 04, 2014 at 10:54:36PM +0900, Masashi Honma wrote: >> 2014-11-04 21:02 GMT+09:00 Bob Copeland <me@bobcopeland.com>: >> > Hmm, does it really matter if you allocate an extra 52 bytes? >> >> I was not reported it causes any problem. >> >> This is just refactoring. > > Ok, I see now, I was confused by the subject which said it reduced frame > size, when it's really changing the size of an allocation. I think this > was in an earlier patch but I left it out to reduce #ifdef clutter -- > but it doesn't matter too much to me either way. > > -- > Bob Copeland %% www.bobcopeland.com
diff --git a/wpa_supplicant/mesh_mpm.c b/wpa_supplicant/mesh_mpm.c index 07ab963..913ec45 100644 --- a/wpa_supplicant/mesh_mpm.c +++ b/wpa_supplicant/mesh_mpm.c @@ -220,21 +220,28 @@ static void mesh_mpm_send_plink_action(struct wpa_supplicant *wpa_s, u8 ie_len, add_plid = 0; int ret; int ampe = conf->security & MESH_CONF_SEC_AMPE; + size_t buf_len; if (!sta) return; - buf = wpabuf_alloc(2 + /* capability info */ - 2 + /* AID */ - 2 + 8 + /* supported rates */ - 2 + (32 - 8) + - 2 + 32 + /* mesh ID */ - 2 + 7 + /* mesh config */ - 2 + 26 + /* HT capabilities */ - 2 + 22 + /* HT operation */ - 2 + 23 + /* peering management */ - 2 + 96 + /* AMPE */ - 2 + 16); /* MIC */ + buf_len = 2 + /* capability info */ + 2 + /* AID */ + 2 + 8 + /* supported rates */ + 2 + (32 - 8) + + 2 + 32 + /* mesh ID */ + 2 + 7 + /* mesh config */ + 2 + 23 + /* peering management */ + 2 + 96 + /* AMPE */ + 2 + 16; /* MIC */ +#ifdef CONFIG_IEEE80211N + if (type != PLINK_CLOSE && + wpa_s->current_ssid->mesh_ht_mode > CHAN_NO_HT) { + buf_len += 2 + 26 + /* HT capabilities */ + 2 + 22; /* HT operation */ + } +#endif /* CONFIG_IEEE80211N */ + buf = wpabuf_alloc(buf_len); if (!buf) return;