This patch adds a parallel crypto template that takes a crypto
algorithm and converts it to process the crypto transforms in
parallel. For the moment only aead is supported.
Signed-off-by: Steffen Klassert
---
crypto/Kconfig| 13 ++
crypto/Makefile |2 +
crypto/pcrypt
This patch adds a parallel crypto template that takes a crypto
algorithm and converts it to process the crypto transforms in
parallel. For the moment only aead is supported.
Signed-off-by: Steffen Klassert
---
crypto/Kconfig | 13 ++
crypto/Makefile|2 +
crypto/pcry
This patch adds a parallel crypto template that takes a crypto
algorithm and converts it to process the crypto transforms in
parallel. For the moment only aead algorithms are supported.
Signed-off-by: Steffen Klassert
---
crypto/Kconfig | 10 +
crypto/Makefile |1 +
crypto
On Mon, Aug 31, 2009 at 11:14:42AM +0200, Steffen Klassert wrote:
> This patch adds a parallel crypto template that takes a crypto
> algorithm and converts it to process the crypto transforms in
> parallel. For the moment only aead is supported.
>
> Signed-off-by: Steffen Klassert
I'll pick this
From: Steffen Klassert
Date: Thu, 8 Oct 2009 09:28:18 +0200
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 1af1e4b..6bc5dde 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -350,6 +350,8 @@ enum
> TASKLET_SOFTIRQ,
> SCHED_SO
On Thu, Oct 08, 2009 at 11:18:33PM -0700, David Miller wrote:
>
> Steffen are we going to end up adding a softirq for every crypto
> transform type?
>
> That won't work, softirqs are to be scarcely allocated and operate
> at a very high level.
>
> I can think of two alternatives:
>
> 1) One sof
On Thu, Oct 08, 2009 at 11:18:33PM -0700, David Miller wrote:
>
> Steffen are we going to end up adding a softirq for every crypto
> transform type?
>
> That won't work, softirqs are to be scarcely allocated and operate
> at a very high level.
>
I changed padata to use workqueues instead of sof
On Fri, Oct 30, 2009 at 11:06:09AM +0100, Steffen Klassert wrote:
>
> If we use tunnel mode, xfrm_input() calls netif_rx() which is certainly
> wrong if we are in thread context, we need to call netif_rx_ni() instead.
Since this is all happening through a crypto completion call,
it needs to be do
On Fri, Oct 30, 2009 at 08:58:18AM -0400, Herbert Xu wrote:
>
> Since this is all happening through a crypto completion call,
> it needs to be done with BH off since that's a requirement for
> crypto completion functions. So netif_rx will work correctly
> as when BH is reenabled it'll pick up the
On Fri, Oct 30, 2009 at 02:27:34PM +0100, Steffen Klassert wrote:
>
> Ok, if it's required that BHs are off then everything is fine.
> In fact I solved this problem for pcrypt by switching off the BHs.
> I just was not sure whether this is the right way to do.
Yeah having random contexts for compl
From: Herbert Xu
Date: Fri, 30 Oct 2009 09:30:55 -0400
> On Fri, Oct 30, 2009 at 02:27:34PM +0100, Steffen Klassert wrote:
>> I'm going to send a workqueue based version of padata/pcrypt
>> within the next week.
>
> Awesome!
Thanks a lot for continuing this work Steffen.
--
To unsubscribe from
11 matches
Mail list logo
