Messages in this thread | | | Date | Wed, 27 Jul 2022 18:52:27 +0300 | Subject | Re: [PATCH 0/6] net/crypto: Introduce crypto_pool | From | Leonard Crestez <> |
| |
On 7/27/22 03:17, Herbert Xu wrote: > On Tue, Jul 26, 2022 at 09:15:54PM +0100, Dmitry Safonov wrote: >> Add crypto_pool - an API for allocating per-CPU array of crypto requests >> on slow-path (in sleep'able context) and to use them on a fast-path, >> which is RX/TX for net/ users (or in any other bh-disabled users). >> The design is based on the current implementations of md5sig_pool. >> >> Previously, I've suggested to add such API on TCP-AO patch submission [1], >> where Herbert kindly suggested to help with introducing new crypto API. > > What I was suggesting is modifying the actual ahash interface so > that the tfm can be shared between different key users by moving > the key into the request object.
The fact that setkey is implemented at the crypto_ahash instead of the ahash_request level is baked into all algorithm implementations (including many hardware-specific ones). Changing this seems extremely difficult.
Supporting setkey at the tfm level could be achieved by making it an optional capability on a per-algorithm basis, then something like crypto_pool could detect this scenario and avoid allocating a per-cpu tfm. This would also require a crypto_pool_setkey wrapper.
As it stands right now multiple crypto-api users needs to duplicate logic for allocating a percpu array of transforms so adding this "pool" API is an useful step forward.
As far as I remember the requirement for a per-cpu scratch buffer is based on weird architectures having limitations on what kind of memory can be passed to crypto api so this will have to remain.
-- Regards, Leonard
| |