Hi Norman
Thanks for your answer.
I wonder, is performance your primary motivation? If so, there might be other opportunities for optimization that are worth implementing first, before resorting to hardware acceleration. Should your primary motivation be the hiding of the keys from software, that's really cool!
Our primary motivation is indeed hiding the keys from the software and reducing the risk of side channel attacks via timing or power analysis. Offloading the computation from the CPU is a nice side benefit though.
I cannot speak for the 'Cbe_crypto::Interface' specifically. But in general, a VFS plugin with outstanding requests is polled for the completion (request_complete) each time after I/O happened, i.e., after an I/O signal occurred.
This mechanism doesn't seem to be integrated in the Cbe_crypto::Interface which is why we would like to the opinion of the original author of this interface before adapting it.
To support batches of outstanding requests at the VFS (for hiding the latency of the crypto device), one may consider maintaining multiple file handles (at the client of the VFS plugin) where each file handle can have one request in flight. So the degree of parallelism can be tuned by the number of open file handles. Right now, I think that the CBE does not schedule more than one crypto request at a time though.
For the moment I'm just trying to avoid polling and multi-threading although latency might be a concern later on.
Best regards Stefan