Hi Stefan,
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.
even though I'm not the author for the 'Cbe_crypto' interface, let me clarify how the control flow of asynchronous I/O works in the VFS in general.
The control flow is always driven by the client of the VFS, e.g., the libc or the VFS server. Whenever the client detects that I/O happened (an I/O signal occurred), it checks each outstanding VFS request for possible progress. In the case of the CBE, there is a chain. For example, the CBE client requests the reading of a block. The CBE, in turn, requests the 'Cbe_crypto' to decrypt data as a prerequisite of finishing the block-read request.
Each time, some I/O happened, the client (e.g., the libc's 'read') asks the VFS for possible progress of the read request (by calling 'complete_read'). This call eventually reaches the CBE. The CBE, in turn, checks the progress of its outstanding crypto operation ('complete_read'). This is what I meant with polling. It is not busy polling but checking for progress each time after I/O happened. This checking is done transitively (libc checks the VFS, VFS checks the CBE, CBE checks crypto).
For this to work, one has to make sure that the I/O backends of the VFS plugins use 'Io_signal_handler' not mere 'Signal_handler' for the reception of asynchronous events like your device interrupt. Otherwise the VFS client won't notice that I/O happened. You may follow the use of the 'Io_progress_handler' interface in base/entrypoint.h to connect the dots.
Hence, there is no special feature in the 'Cbe_crypto::Interface' needed to support asynchronous operation. The pair of 'request' (submit work) and 'complete' (check the state of the submitted work) functions suffices.
However, as I said above, I've no experience with the 'Cbe_crypto' interface specifically and hope that I'm not telling anything wrong.
Maybe Martin or Josef can chime in to substantiate?
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.
Sorry for the confusion. I was not speaking of busy polling or multi-threading at all. If the batching of crypto operations is not a concern of you (right now), please better ignore this paragraph.
Cheers Norman