Re: [PATCH RESEND 0/2] crypto: algif - change algif_skcipher to be asynchronous
Hi Stephan, On 03/08/2015 11:20 AM, Stephan Mueller wrote: As you may know, I am working on libkcapi [1] to cover the user space AF_ALG interface and provide an easy-to use interface for applications. I am now trying to cover your interface proposal there and also measure the speed of it. What bothers me currently is the following: how would I be able to detect whether the implemented support is available in the current kernel? You don't need to detect that. You can just use the new interface, and in the older kernels without AIO support in skcipher it will seamlessly fallback to the synchronous interface. The only problem is that the socket layer didn't like asynch operations before commit 06539d3071067ff146a9bffd1c801fa56d290909. The way it can be tackled for the older kernels is the distros will need update their kernels with the mentioned commit. They should do it anyway because it looks like that was a bug. One other thing to keep in mind is - to be able to see the benefit of AIO you need to use some encryption offload engine, where you can asynchronously offload multiple operations. With my dh895xxcc engine I see around 8x throughput improvement. Regards, Tadeusz -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 0/2] crypto: algif - change algif_skcipher to be asynchronous
Am Freitag, 27. Februar 2015, 11:35:38 schrieb Tadeusz Struk: Hi Tadeusz, The way the algif_skcipher works currently is that on sendmsg/sendpage it builds an sgl for the input data and then on read/recvmsg it sends the job for encryption putting the user to sleep till the data is processed. This way it can only handle one job at a given time. To be able to fuly utilize the potential of existing crypto hardware accelerators it is required to submit multiple jobs in asynchronously. This series adds support for asynchronous operations for algif_skcipher. First patch enables af_alg sgl to be linked. Second patch implement asynch read for skcipher. Resend with updates for 4.0 As you may know, I am working on libkcapi [1] to cover the user space AF_ALG interface and provide an easy-to use interface for applications. I am now trying to cover your interface proposal there and also measure the speed of it. What bothers me currently is the following: how would I be able to detect whether the implemented support is available in the current kernel? For the different AF_ALG interfaces (like the recently added AEAD), I can detect missing support at the time I call the socket() syscall. Thus, the application knows right from the start whether we have the requested support. But for the AIO interface, how can I detect that at runtime at a time an application can reasonably catch a missing support? [1] http://www.chronox.de/libkcapi.html Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com --- Tadeusz Struk (2): crypto: af_alg - Allow to link sgl crypto: algif - change algif_skcipher to be asynchronous crypto/af_alg.c | 18 ++- crypto/algif_skcipher.c | 308 ++- include/crypto/if_alg.h | 4 - 3 files changed, 317 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ciao Stephan -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 0/2] crypto: algif - change algif_skcipher to be asynchronous
The way the algif_skcipher works currently is that on sendmsg/sendpage it builds an sgl for the input data and then on read/recvmsg it sends the job for encryption putting the user to sleep till the data is processed. This way it can only handle one job at a given time. To be able to fuly utilize the potential of existing crypto hardware accelerators it is required to submit multiple jobs in asynchronously. This series adds support for asynchronous operations for algif_skcipher. First patch enables af_alg sgl to be linked. Second patch implement asynch read for skcipher. Resend with updates for 4.0 Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com --- Tadeusz Struk (2): crypto: af_alg - Allow to link sgl crypto: algif - change algif_skcipher to be asynchronous crypto/af_alg.c | 18 ++- crypto/algif_skcipher.c | 308 ++- include/crypto/if_alg.h |4 - 3 files changed, 317 insertions(+), 13 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
