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@vger.kernel.org/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
