On Thu, Sep 26, 2019 at 07:54:03PM -0700, Linus Torvalds wrote:

There's no "read_potentially_async()" interface that just does the
synchronous read for any cached portion of the data, and then delays
just the IO parts and returns a "here, I gave you X bytes right now,
use this cookie to wait for the rest".

Incidentally this is exactly how the crypto async interface works.
For example, the same call works whether you're sync or async:

	aead_request_set_callback(req, ...);
	aead_request_set_crypt(req, ...);
	err = crypto_aead_encrypt(req);
	if (err == -EINPROGRESS)
		/*
		 * Request is processed asynchronously.
		 * This cannot occur if the algorithm is sync,
		 * e.g., when you specifically allocated sync
		 * algorithms.
		 */
	else
		/* Request was processed synchronously */

We even allow the request to be on the stack in the sync case, e.g.,
with SYNC_SKCIPHER_REQUEST_ON_STACK.

Maybe nobody would use it. But it really should be possibly to have
interfaces where a good synchronous implementation is _possible_
without the extra overhead, while also allowing async implementations.

So there is really no async overhead in the crypto API AFAICS if
you're always doing sync.  What you see as overheads are probably
the result of having to support multiple underlying algorithms
(not just accelerations which can indeed be handled without
indirection at least for CPU-based ones).

Cheers,
-- 
Email: Herbert Xu [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel