Re: Questions about the Crypto API

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

 



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.

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@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




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

  Powered by Linux