On 14 October 2016 at 10:25, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Fri, 2016-10-14 at 10:21 +0100, Ard Biesheuvel wrote: > >> It is annotated with a TODO, though :-) >> >> 38320c70d282b (Herbert Xu 2008-01-28 19:35:05 >> -0800 41) >> * TODO: Use spare space in skb for this where possible. > > I saw that, but I don't think generally there will be spare space for > it - the stuff there is likely far too big. Anyway ... same problem > that we have. > > I'm not inclined to allocate ~500 bytes temporarily for every frame > either though. > > Maybe we could try to manage it in mac80211, we'd "only" need 5 AEAD > structs (which are today on the stack) in parallel for each key (4 TX, > 1 RX), but in a typical case of having 3 keys that's already 7.5K worth > of memory that we almost never use. Again, with more complexity, we > could know that the TX will not be used if the driver does the TX, but > the single RX one we'd need unconditionally... decisions decisions... > So why is the performance hit acceptable for ESP but not for WPA? We could easily implement the same thing, i.e., kmalloc(GFP_ATOMIC)/kfree the aead_req struct rather than allocate it on the stack -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
