Ranting about OCF / crypto(9)

[Emeric POUPON]

> - We need to not treat accelerated software (e.g. AES-NI) as a
>  hardware interface.  Right now OCF's model of priorities when
>  trying to choose a backend driver for a session only has two
>  "levels" software vs hardware and aesni(4) (and the ARMv8 variant)
>  are lumped into the hardware bucket so that they have precedence
>  over the "dumb" software implementation.  However, the accelerated
>  software algorithms do need some of the same support features of
>  the "dumb" software implementation (such as being scheduled on a
>  thread pool to use CPU cycles) that are not needed by other "hardware"
>  engines.  OCF needs to understand this distinction.

Hello,

As you already mentioned before, we cannot benefit from aesni(4) with IPSec on Intel platforms, except when using AEAD algorithms like GCM.

Maybe we should not expose accelerated software (e.g. AESNI) as crypto drivers. Plugging them directly into cryptosoft brings some benefits:
- no duplicate code about crypto session handling,
- partially accelerated crypto (e.g. aesni for AES-CBC, soft for SHA256. Useful for IPSec),
- possible use of the 'async' mode to process crypto jobs using a thread pool.

Actually that's something we already did using straightforward, internal patches.
Now I would like to know what you think about this idea and what you would suggest to achieve this? (using a new framework?)

Regards,

Emeric