Re: crypto API - async semantics

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux