On Thu, 10 Jan 2013 00:49:23 -0600 Garg Vakul-B16394 <B16394@xxxxxxxxxxxxx> wrote: > > From: Phillips Kim-R1AAHA > > Sent: Thursday, January 10, 2013 3:16 AM > > On Sat, 5 Jan 2013 17:14:13 +0000 > > Garg Vakul-B16394 <B16394@xxxxxxxxxxxxx> wrote: > > > > From: Jussi Kivilinna [mailto:jussi.kivilinna@xxxxxxxx] > > > > Sent: Saturday, January 05, 2013 9:56 PM > > > > > > > > Quoting Vakul Garg <vakul@xxxxxxxxxxxxx>: > > > > > > > > > This allows to test & run multiple parallel crypto ahash contexts. > > > > > Each of the test vector under the ahash speed test template is > > > > > started under a separate kthread. > > > > > > > > Why you want to do this? > > > > > > In its current form, we cannot test multiple simultaneous crypto > > sessions with tcrypt. > > > Crypto offload hardware accelerators are usually capable of handling > > multiple session in parallel. > > > This patch allows to load such hardware. > > > > tcrypt can currently test offload engines with multiple single-session > > async requests. So to test multiple _session_ requests, why isn't the > > change to tcrypt simply to alternate keys in the request loop, as opposed > > to what this patch does, i.e. > > adding separate kthreads? The number of sessions/keys to alternate can > > be added as a module parameter. > > > > > Even if offload accelerators are not present, multiple crypto sessions > > can execute in parallel on Multicore. > > > > I think that's more in the area of PCRYPT. > > > > > > > > Does not this change make tcrypt give inconsistent results? > > > > > > > > > > Based on kernel scheduling of threads, this change can make tcrypt give > > varying results in different runs. > > > For consistent results, we can use existing synchronous mode crypto > > sessions. > > > > see above. I'm not sure, but I think multithreading tcrypt should be > > left to the parallel crypto engine (PCRYPT) and Software async crypto > > daemon (CRYPTD). > [VG] IIUC, PCRYPT and CRYPTD provides infrastructure to execute crypto contexts under threads to achieve different things. > PCRYPT allows multiple crypto requests from a transform to execute in parallel. > > CRYPTD provides a daemon which executes crypto requests. > It is more like crypto hardware accelerator running in software (e.g. on a certain core of Multicore processor). > > My proposal is to add capability in tcrypt to launch multiple parallel crypto transforms. but you can do that in a single thread - it's up to the algorithm implementation (be it a driver, pcrypt, sync s/w, etc.) to parallelize the requests appropriately for the underlying h/w. > Currently, only one transform is active at any point of time. so allocate multiple transforms at startup and round-robin through them in the single-threaded test loop? btw, tcrypt's existing async cipher implementation (commit 3f3baf3 "crypto: tcrypt - add test_acipher_speed") waits for request completion prior to submitting a new request - not good for h/w with parallel cipher capabilities. Here's a version that suits the SEC4 better: http://marc.info/?l=linux-crypto-vger&m=128179098817896&w=2 Kim -- 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
