The idea is that hardware acceleration is a niche feature, so it should be kept out of the core, low-level crypto primitives, and then a higher-level API can be built that allows dynamic dispatch to an accelerator if available:

https://lkml.org/lkml/2018/8/3/15

> A very large majority of in-kernel crypto users (by number of call sites under a very brief survey, not by number of CPU cycles) just want to do some synchronous crypto on a buffer that is addressed by a regular pointer. Most of these users would be slowed down if they used any form of async crypto, since the CPU can complete the whole operation faster than it could plausibly initiate and complete anything asynchronous. And, right now, they suffer the full overhead of allocating a context (often with alloca!), looking up (or caching) some crypto API data structures, dispatching the operation, and cleaning up.

> So I think the right way to do it is to have directly callable functions like zinc uses and to have the fancy crypto API layer on top of them. So if you actually want async accelerated crypto with scatterlists or whatever, you can call into the fancy API, and the fancy API can dispatch to hardware or it can dispatch to the normal static API.

I guess they don't count CPU instruction based accelerators like AES-NI as accelerators?

They do not. The difference is the same as having a BLAS implementation that uses the SIMD units to their potential and one that supports a dedicated sparse matrix multiply ASIC connected via some high bandwidth bus. In the first case the caller doesn't have to worry about the implementation details it is just a performance optimization. In the other case you have to use an API that has to be more cumbersome to deal with multiplexing the accelerator and moving data.

Correct

That makes sense. Thanks!