On Tue, Aug 13, 2013 at 07:25:50PM +0000, Hsieh, Che-Min wrote: > > Garg: For any tfm, blkcipher or ablkcipher, they must return results > > in the order they were given. For a blkcipher which is synchronous, > > this is always true by definition since we return only after the > > result has been completed. For an async ablkcipher, this means that > > if you receive two requests on the same CPU, then the first request > > must be served and completed before the second request's completion > > can be initiated. > > Herbert, can you give further clarification: > (*) This ordering of result is also true for others, such as aead and hashing, right? Correct. > Can you confirm, or correct the following statements: > (*)To perform hashing on a long data stream, it may come in multiple requests to the driver; in a sequence of one .init request, one or more than one .update requests, and lastly one .final request. In this sequence, a request has to be complete, before next one to be issued to the driver. Those requests should always come in the same struct crypto_async_request. > Is this correct? No. Operations can always be interleaved, i.e., two different requests can both start with init and then update in lock-step. For hashes all state must be confined to the context area of ahash_request. That is, the hardware must not maintain internal state, or if it does, it must be prepared to refresh its state if an ahash_request comes in that does not agree with the hardware's current state. Now, I understand that not all hardware makes it easy to do this, that is why we don't require all hardware to provide the init/update/final interface. The hardware can provide only the digest interface (and most likely the finup interface) and then rely on a software fall-back for the "stateless" init/update/final operations. Accordingly, on the user side we encourage everyone to use digest and/or finup wherever possible so that the chances of hardware acceleration is maximised. > If driver needs to maintain state variables for such (init, update, final), the state variables can be maintained in the request implementation context, instead of tfm context. Right? Right. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
