Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

2016-10-18 Thread Ard Biesheuvel
On 18 October 2016 at 15:24, Johannes Berg wrote: > On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote: >> >> > Hmm. Is it really worth having a per-CPU variable for each possible >> > key? You could have a large number of those (typically three when >> > you're a

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

2016-10-18 Thread Johannes Berg
On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote: >  > > Hmm. Is it really worth having a per-CPU variable for each possible > > key? You could have a large number of those (typically three when > > you're a client on an AP, and 1 + 1 for each client when you're the > > AP). 2 + 1 for each

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

2016-10-18 Thread Ard Biesheuvel
On 18 October 2016 at 15:16, Johannes Berg wrote: > On Tue, 2016-10-18 at 15:08 +0100, Ard Biesheuvel wrote: >> >> + aead_req = *this_cpu_ptr(ccmp->reqs); >> + if (!aead_req) { >> + aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC); >> +

[RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

2016-10-18 Thread Ard Biesheuvel
Now that we can no longer invoke AEAD transforms with the aead_request structure allocated on the stack, we perform a kmalloc/kfree for every packet, which is expensive. Since the CCMP routines execute in softirq context, we know there can never be more than one request in flight on each CPU, and