lkml.org 
[lkml]   [2022]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 0/6] net/crypto: Introduce crypto_pool
From
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

\
 
 \ /
  Last update: 2022-07-27 17:53    [W:0.124 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site