On 10/12/2017 9:44 AM, Herbert Xu wrote: > On Wed, Oct 11, 2017 at 12:36:11PM +0000, Horia Geantă wrote: >> Hi Herbert, >> >> I am evaluating whether ahash implementation in caam crypto driver >> behaves correctly. >> One thing I've noticed is that for each ahash tfm there is support for >> at most two in-flight requests, and I would like to know whether this is >> an issue or not. > > What do you mean by in-flight requests? If you're talking about > requests that have not been completed (i.e., in progress) then > that's fine. Any new requests coming in can just be queued. > > If you're talking about requests that have not been finalised > then that would be broken. The API allows an arbitrary number > of requests to ben present in an non-finalised state. For example, > given an IPsec SA, we may be processing any number of packets for > it at once, with each coming from a different CPU. > Taking ascii art from crypto API docs: DATA -----------. v .init() -> .update() -> .final() ! .update() might not be called ^ | | at all in this scenario. '----' '---> HASH My question was referring to the case where multiple update() operations are issued in parallel for the same request object. For e.g. let's say a crypto API client wants to hash a 4GB file, and does this by issuing update() repeatedly and performing wait_for_completion() at the very end. >> In this context, could you please clarify whether your previous answer: >> https://www.mail-archive.com/linux-crypto@xxxxxxxxxxxxxxx/msg04029.html >>> If any async operation returns EINPROGRESS, the client must not >>> proceed until that operation has completed. >> refers only to ahash operations OR to any crypto API async operation? >> IIUC this would be equivalent to saying that crypto API allows only for >> one in-flight request per tfm, correct? > > No that comment is referring to the request object. The whole point > of having a request object is to allow arbitrary number of hash > operations in parallel given a single tfm. The tfm is simply a > representation of the key. All hash state must be stored in the > request. > Got it, thanks. Horia