On Mon, May 31, 2010 at 10:44:30PM -0400, Mikulas Patocka wrote: > Questions: > > If you are optimizing it, > > 1) why don't you optimize it in such a way that if one CPU submits > requests, the crypto work is spread among all the CPUs? Currently it > spreads the work only if different CPUs submit it. Because the crypto layer already provides that functionality, through pcrypt. By instantiating pcrypt for a given algorithm, you can parallelise that algorithm across CPUs. This would be inappropriate for upper layer code as they do not know whether the underlying algorithm should be parallelised, e.g., a PCI offload board certainly should not be parallelised. > 2) why not optimize software async crypto daemon (crypt/cryptd.c) instead > of dm-crypt, so that all kernel subsystems can actually take advantage of > those multi-CPU optimizations, not just dm-crypt? Because you cannot do what Andi is doing here in the crypto layer. What dm-crypt does today (which hasn't always been the case BTW) hides information away (the original submitting CPU) that we cannot recreate. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
