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

On 18 October 2016 at 15:24, Johannes Berg [off-list ref] wrote:

On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote:

quoted

quoted

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 client, actually, since you have 2 GTKs present in the
"steady state"; not a big difference though.

quoted

quoted

Would it be so bad to have to set the TFM every time (if that's
even possible), and just have a single per-CPU cache?

quoted

That would be preferred, yes. The only snag here is that
crypto_alloc_aead() is not guaranteed to return the same algo every
time, which means the request size is not guaranteed to be the same
either. This is a rare corner case, of course, but it needs to be
dealt with regardless

Ah, good point. Well I guess you could allocate a bigger one it if it's
too small, but then we'd have to recalculate the size all the time
(which we already did anyway, but saving something else would be good).
Then we'd be close to just having a per-CPU memory block cache though.

Well, ideally we'd allocate the ccm(aes) crypto_alg a single time and
'spawn' the transforms for each key. This is how the crypto API
implements templates internally, but I don't think this functionality
is publicly accessible. Herbert?