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.
Signed-off-by: Vakul Garg <[email protected]>
---
crypto/tcrypt.c | 164 +++++++++++++++++++++++++++++++++++++++++++------------
1 files changed, 129 insertions(+), 35 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 7ae2130..e879de9 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -33,6 +33,7 @@
#include <linux/jiffies.h>
#include <linux/timex.h>
#include <linux/interrupt.h>
+#include <linux/kthread.h>
#include "tcrypt.h"
#include "internal.h"
@@ -497,9 +498,9 @@ static inline int do_one_ahash_op(struct ahash_request *req, int ret)
}
return ret;
}
-
static int test_ahash_jiffies_digest(struct ahash_request *req, int blen,
- char *out, int sec)
+ char *out, int sec,
+ struct completion *comp)
{
unsigned long start, end;
int bcount;
@@ -512,6 +513,11 @@ static int test_ahash_jiffies_digest(struct ahash_request *req, int blen,
return ret;
}
+ wait_for_completion_interruptible(comp);
+
+ pr_info("test (%5u byte blocks,%5u bytes per update,%4u updates): ",
+ blen, blen, blen/blen);
+
printk("%6u opers/sec, %9lu bytes/sec\n",
bcount / sec, ((long)bcount * blen) / sec);
@@ -519,14 +525,15 @@ static int test_ahash_jiffies_digest(struct ahash_request *req, int blen,
}
static int test_ahash_jiffies(struct ahash_request *req, int blen,
- int plen, char *out, int sec)
+ int plen, char *out, int sec,
+ struct completion *comp)
{
unsigned long start, end;
int bcount, pcount;
int ret;
if (plen == blen)
- return test_ahash_jiffies_digest(req, blen, out, sec);
+ return test_ahash_jiffies_digest(req, blen, out, sec, comp);
for (start = jiffies, end = start + sec * HZ, bcount = 0;
time_before(jiffies, end); bcount++) {
@@ -544,6 +551,11 @@ static int test_ahash_jiffies(struct ahash_request *req, int blen,
return ret;
}
+ wait_for_completion_interruptible(comp);
+
+ pr_info("test (%5u byte blocks,%5u bytes per update,%4u updates): ",
+ blen, plen, blen/plen);
+
pr_cont("%6u opers/sec, %9lu bytes/sec\n",
bcount / sec, ((long)bcount * blen) / sec);
@@ -551,7 +563,7 @@ static int test_ahash_jiffies(struct ahash_request *req, int blen,
}
static int test_ahash_cycles_digest(struct ahash_request *req, int blen,
- char *out)
+ char *out, struct completion *comp)
{
unsigned long cycles = 0;
int ret, i;
@@ -582,6 +594,11 @@ out:
if (ret)
return ret;
+ wait_for_completion_interruptible(comp);
+
+ pr_info("test (%5u byte blocks,%5u bytes per update,%4u updates): ",
+ blen, blen, blen/blen);
+
pr_cont("%6lu cycles/operation, %4lu cycles/byte\n",
cycles / 8, cycles / (8 * blen));
@@ -589,13 +606,13 @@ out:
}
static int test_ahash_cycles(struct ahash_request *req, int blen,
- int plen, char *out)
+ int plen, char *out, struct completion *comp)
{
unsigned long cycles = 0;
int i, pcount, ret;
if (plen == blen)
- return test_ahash_cycles_digest(req, blen, out);
+ return test_ahash_cycles_digest(req, blen, out, comp);
/* Warm-up run. */
for (i = 0; i < 4; i++) {
@@ -636,51 +653,119 @@ static int test_ahash_cycles(struct ahash_request *req, int blen,
}
out:
+
if (ret)
return ret;
+ wait_for_completion_interruptible(comp);
+
+ pr_info("test (%5u byte blocks,%5u bytes per update,%4u updates): ",
+ blen, plen, blen/plen);
+
pr_cont("%6lu cycles/operation, %4lu cycles/byte\n",
cycles / 8, cycles / (8 * blen));
return 0;
}
-static void test_ahash_speed(const char *algo, unsigned int sec,
- struct hash_speed *speed)
+struct hash_test {
+ const char *algo;
+ unsigned int blen;
+ unsigned int plen;
+ unsigned int klen;
+ unsigned int sec;
+ struct completion print;
+ struct completion finish;
+};
+
+static int test_ahash_speed_thread(void *data)
{
struct scatterlist sg[TVMEMSIZE];
struct tcrypt_result tresult;
struct ahash_request *req;
struct crypto_ahash *tfm;
static char output[1024];
- int i, ret;
-
- printk(KERN_INFO "\ntesting speed of async %s\n", algo);
+ int ret;
+ struct hash_test *test = data;
- tfm = crypto_alloc_ahash(algo, 0, 0);
+ tfm = crypto_alloc_ahash(test->algo, 0, 0);
if (IS_ERR(tfm)) {
pr_err("failed to load transform for %s: %ld\n",
- algo, PTR_ERR(tfm));
- return;
+ test->algo, PTR_ERR(tfm));
+ ret = PTR_ERR(tfm);
+ goto stop;
}
if (crypto_ahash_digestsize(tfm) > sizeof(output)) {
pr_err("digestsize(%u) > outputbuffer(%zu)\n",
crypto_ahash_digestsize(tfm), sizeof(output));
- goto out;
+ ret = -EINVAL;
+ goto err;
}
test_hash_sg_init(sg);
req = ahash_request_alloc(tfm, GFP_KERNEL);
if (!req) {
pr_err("ahash request allocation failure\n");
- goto out;
+ ret = PTR_ERR(req);
+ goto err;
}
init_completion(&tresult.completion);
ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
tcrypt_complete, &tresult);
+
+ ahash_request_set_crypt(req, sg, output, test->plen);
+
+ if (sec)
+ ret = test_ahash_jiffies(req, test->blen,
+ test->plen, output, sec,
+ &test->print);
+ else
+ ret = test_ahash_cycles(req, test->blen,
+ test->plen, output, &test->print);
+
+ if (ret)
+ pr_err("hashing failed ret=%d\n", ret);
+
+ ahash_request_free(req);
+
+err:
+ crypto_free_ahash(tfm);
+
+stop:
+ complete(&test->finish);
+
+ return ret;
+}
+
+
+static void test_ahash_speed(const char *algo, unsigned int sec,
+ struct hash_speed *speed)
+{
+ int i, num_tests;
+ struct hash_test *tests;
+ struct task_struct **threads;
+
+ pr_info("\ntesting speed of async %s\n", algo);
+
+ /* Count the number of tests to be done */
+ for (i = 0; speed[i].blen != 0; i++)
+ ;
+
+ threads = kzalloc(i * sizeof(struct task_struct *), GFP_KERNEL);
+ if (!threads) {
+ pr_err("Memory alloc for threads failed\n");
+ return;
+ }
+
+ tests = kzalloc(i * sizeof(struct hash_test), GFP_KERNEL);
+ if (!threads) {
+ pr_err("Memory alloc for hash tests failed\n");
+ goto err;
+ }
+
for (i = 0; speed[i].blen != 0; i++) {
if (speed[i].blen > TVMEMSIZE * PAGE_SIZE) {
pr_err("template (%u) too big for tvmem (%lu)\n",
@@ -688,29 +773,38 @@ static void test_ahash_speed(const char *algo, unsigned int sec,
break;
}
- pr_info("test%3u "
- "(%5u byte blocks,%5u bytes per update,%4u updates): ",
- i, speed[i].blen, speed[i].plen, speed[i].blen / speed[i].plen);
-
- ahash_request_set_crypt(req, sg, output, speed[i].plen);
-
- if (sec)
- ret = test_ahash_jiffies(req, speed[i].blen,
- speed[i].plen, output, sec);
- else
- ret = test_ahash_cycles(req, speed[i].blen,
- speed[i].plen, output);
-
- if (ret) {
- pr_err("hashing failed ret=%d\n", ret);
+ tests[i].algo = algo;
+ tests[i].blen = speed[i].blen;
+ tests[i].plen = speed[i].plen;
+ tests[i].klen = speed[i].klen;
+ init_completion(&tests[i].print);
+ init_completion(&tests[i].finish);
+
+ /* Create a kthread for the test vector in template */
+ threads[i] = kthread_run(test_ahash_speed_thread, &tests[i],
+ "tcrypt_ahash_%d", i);
+ if (IS_ERR(threads[i])) {
+ pr_err("tcrypt_ahash_%d creation failed\n", i);
break;
}
}
- ahash_request_free(req);
+ num_tests = i;
-out:
- crypto_free_ahash(tfm);
+ /* TODO: Let all threads pass a barrier so that they start
+ * crypto tests together.
+ */
+
+ /* Signal threads one by one for printing results and stop them*/
+ for (i = 0; i < num_tests; i++) {
+ complete(&tests[i].print);
+ /*kthread_stop(threads[i]);*/
+ wait_for_completion_interruptible(&tests[i].finish);
+ }
+
+err:
+ kfree(threads);
+ kfree(tests);
}
static inline int do_one_acipher_op(struct ablkcipher_request *req, int ret)
--
1.7.7.6
Quoting Vakul Garg <[email protected]>:
> 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? Does not this change make tcrypt give
inconsistent results?
> -----Original Message-----
> From: Jussi Kivilinna [mailto:[email protected]]
> Sent: Saturday, January 05, 2013 9:56 PM
> To: Garg Vakul-B16394
> Cc: [email protected]
> Subject: Re: [PATCH][RFC] crypto: tcrypt - Ahash tests changed to run in
> parallel.
>
> Quoting Vakul Garg <[email protected]>:
>
> > 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.
Even if offload accelerators are not present, multiple crypto sessions can execute in parallel on Multicore.
> 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.
On Sat, 5 Jan 2013 17:14:13 +0000
Garg Vakul-B16394 <[email protected]> wrote:
> > From: Jussi Kivilinna [mailto:[email protected]]
> > Sent: Saturday, January 05, 2013 9:56 PM
> >
> > Quoting Vakul Garg <[email protected]>:
> >
> > > 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).
Kim
Hello Kim
> -----Original Message-----
> From: Phillips Kim-R1AAHA
> Sent: Thursday, January 10, 2013 3:16 AM
> To: Garg Vakul-B16394
> Cc: Jussi Kivilinna; [email protected]
> Subject: Re: [PATCH][RFC] crypto: tcrypt - Ahash tests changed to run in
> parallel.
>
> On Sat, 5 Jan 2013 17:14:13 +0000
> Garg Vakul-B16394 <[email protected]> wrote:
>
> > > From: Jussi Kivilinna [mailto:[email protected]]
> > > Sent: Saturday, January 05, 2013 9:56 PM
> > >
> > > Quoting Vakul Garg <[email protected]>:
> > >
> > > > 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.
Currently, only one transform is active at any point of time.
>
> Kim
On Thu, 10 Jan 2013 00:49:23 -0600
Garg Vakul-B16394 <[email protected]> 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 <[email protected]> wrote:
> > > > From: Jussi Kivilinna [mailto:[email protected]]
> > > > Sent: Saturday, January 05, 2013 9:56 PM
> > > >
> > > > Quoting Vakul Garg <[email protected]>:
> > > >
> > > > > 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
> -----Original Message-----
> From: Phillips Kim-R1AAHA
> Sent: Thursday, January 10, 2013 9:21 PM
> To: Garg Vakul-B16394
> Cc: Jussi Kivilinna; [email protected]
> Subject: Re: [PATCH][RFC] crypto: tcrypt - Ahash tests changed to run in
> parallel.
>
> On Thu, 10 Jan 2013 00:49:23 -0600
> Garg Vakul-B16394 <[email protected]> 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 <[email protected]> wrote:
> > > > > From: Jussi Kivilinna [mailto:[email protected]]
> > > > > Sent: Saturday, January 05, 2013 9:56 PM
> > > > >
> > > > > Quoting Vakul Garg <[email protected]>:
> > > > >
> > > > > > 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?
Current tcrypt structure waits for a crypto job to complete before sending next one.
Even if I create multiple transforms at startup, they would still run serially if
I use single thread. And if I do not wait for a response to previous job before
sending next job (belonging to different transform), I have to do all the housekeeping
in same thread for co-relating responses to requests. Having multiple kthreads is a
convenient way to achieve the above as each kthread is responsible for only one
transform. Also multiple kthreads running on multiple cores may easily stress SEC
without single core becoming bottleneck.
>
> 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
Thanks. I will check this.
>
> Kim
Quoting Garg Vakul-B16394 <[email protected]>:
>
>> 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.
But one cannot get consistent results for asynchronous software
implementations after this patch.
-Jussi
> -----Original Message-----
> From: Jussi Kivilinna [mailto:[email protected]]
> Sent: Saturday, January 19, 2013 5:25 AM
> To: Garg Vakul-B16394
> Cc: [email protected]
> Subject: RE: [PATCH][RFC] crypto: tcrypt - Ahash tests changed to run in
> parallel.
>
> Quoting Garg Vakul-B16394 <[email protected]>:
>
> >
> >> 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.
>
> But one cannot get consistent results for asynchronous software
> implementations after this patch.
Should we launch threads optionally based on module argument (in both synchronous and async mode)?
This would preserve existing tcrypt behavior.
>
> -Jussi
>
>
Quoting Garg Vakul-B16394 <[email protected]>:
>
>
>> -----Original Message-----
>> From: Jussi Kivilinna [mailto:[email protected]]
>> Sent: Saturday, January 19, 2013 5:25 AM
>> To: Garg Vakul-B16394
>> Cc: [email protected]
>> Subject: RE: [PATCH][RFC] crypto: tcrypt - Ahash tests changed to run in
>> parallel.
>>
>> Quoting Garg Vakul-B16394 <[email protected]>:
>>
>> >
>> >> 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.
>>
>> But one cannot get consistent results for asynchronous software
>> implementations after this patch.
>
> Should we launch threads optionally based on module argument (in
> both synchronous and async mode)?
> This would preserve existing tcrypt behavior.
Yes, that would be better.
-Jussi