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 <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
