Re: Questions about the Crypto API

[Marcelo Cerri <mhcerri@linux.vnet.ibm.com>]

On Sat, Aug 10, 2013 at 11:15:41AM +1000, Herbert Xu wrote:
> On Fri, Aug 09, 2013 at 01:09:12PM +0000, Hsieh, Che-Min wrote:
> > Marcelo/Herbert:
> > 
> > I believe It is. Herbert, please correct me if I am wrong.
> > A single tfm is used as a user context to crypto, so to speak. But a user is not a thread.
> > Let us use ipsec as example.
> > For each security association (SA), it will take up a tfm.
> > Assume I have IP sec setup between my local host and remote host.  I might have two SA's, one for each direction.
> > Now, I might run ping. Simultaneously, I might run iperf. I might run a lot of different things  between these two ip hosts.
> > But only two tfm's are involved.
> > I have seen this happening   in our system with ipsec setup as described above.
> > While an  async request is outstanding in the driver,  another request is  issued to the same driver for the same tfm.
> 
> Yes you're absolutely right.
> 
> Unless I've misunderstood Marcelo's question is different from
> what Garg was asking.
> 
> Marcelo: The tfm, be it blkcipher or ablkcipher can always be used
> in parallel by the user on different CPUs.  For example, IPsec may
> receive two packets on two CPUs through the same SA, in which case
> decryption will be carried out in parallel.

So does that means that it's possible to keep data in the tfm's context
that is the same for a single SA, such as the AES expanded key, but it's
not possible to keep data that is specific for the current operation,
such as an operation state that the driver might require?

Actually I think that probably I have misunderstood the blkcipher
interface, so here it is another question: is each encrypt/decrypt call
a complete operation? I mean, I'm considering that I could always chain
a series of calls to encrypt data in separated chunks, in a similar way
that is done for the hash interface and because that I'm assuming that I
would have to keep state between those calls if the device requires
that.

> 
> 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.
> 
> Sorry for any confusion this might have caused.
> 
> Cheers,
> -- 
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>