. Instead everything runs in a single thread of
execution. You had suggested that the SIMD wrapper will defer the job to
the Kthread context, but I am not sure that will be done.
Please let me know what you think.
Signed-off-by: Megha Dey <megha@linux.intel.com>
---
arch/x86/crypto/s
On Thu, 2018-01-18 at 22:39 +1100, Herbert Xu wrote:
> On Tue, Jan 09, 2018 at 04:09:04PM -0800, Megha Dey wrote:
> >
> > +static void mcryptd_skcipher_encrypt(struct crypto_async_request *base,
> > + int err)
multi-buffer encryption build
support.
For an introduction to the multi-buffer implementation, please see
http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey
This patch introduces the assembly routine to do a by8 AES CBC
encryption in support of the AES CBC multi-buffer implementation.
It encrypts 8 data streams of the same key size simultaneously.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey
-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/Makefile| 1 +
arch/x86/crypto/aes-cbc-mb/Makefile | 22 +
arch/x86/crypto/aes-cbc-mb/
completed state.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c | 146
arch/x86/crypto/aes-cbc-mb/m
<mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h| 97 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h| 132
arch/x86
ablkcipher_walk helpers to walk the scatter gather list
and eliminated needs to modify blkcipher_walk for multibuffer cipher
v2
1. Update cpu feature check to make sure SSE is supported
2. Fix up unloading of aes-cbc-mb module to properly free memory
Megha Dey (5):
crypto: Multi-buffer encryption
On Thu, 2017-08-03 at 13:27 +0800, Herbert Xu wrote:
> On Tue, Jul 25, 2017 at 07:09:58PM -0700, Megha Dey wrote:
> >
> > +/* notify the caller of progress ; request still stays in queue */
> > +
> > +static void notify_callback(struct mcryptd
<jstan...@redhat.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Reported-by: Jan Stancek <jstan...@redhat.com>
---
arch/x86/crypto/sha1_avx2_x86_64_asm.S | 67 ++
arch/x86/crypto/sha1_ssse3_glue.c | 2 +-
2 files changed, 37 insertions(+
On Wed, 2017-08-02 at 10:13 -0700, Megha Dey wrote:
> It was reported that the sha1 AVX2 function(sha1_transform_avx2) is
> reading ahead beyond its intended data, and causing a crash if the next
> block is beyond page boundary:
> http://marc.info/?l=linux-crypto-vger=149
.
It passes the tests written by Jan Stancek that revealed this problem:
https://github.com/jstancek/sha1-avx2-crash
I have re-enabled sha1-avx2 by reverting commit
b82ce24426a4071da9529d726057e4e642948667
Originally-by: Ilya Albrekht <ilya.albre...@intel.com>
Signed-off-by: Megha Dey
.
It passes the tests written by Jan Stancek that revealed this problem:
https://github.com/jstancek/sha1-avx2-crash
Jan, can you verify this fix?
Herbert, can you re-enable sha1-avx2 once Jan has checked it out and
revert commit b82ce24426a4071da9529d726057e4e642948667 ?
Signed-off-by: Megha Dey
On Tue, 2017-07-25 at 19:09 -0700, Megha Dey wrote:
> In this patch series, we introduce AES CBC encryption that is parallelized on
> x86_64 cpu with XMM registers. The multi-buffer technique encrypt 8 data
> streams in parallel with SIMD instructions. Decryption is handled as in the
&
For more robust testing of AES CBC multibuffer support, additional
test vectors have been added to the AES CBC encrypt/decrypt
test case.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim C
On Tue, 2017-07-25 at 10:17 +0800, Herbert Xu wrote:
> On Mon, Jul 24, 2017 at 06:09:56PM -0700, Megha Dey wrote:
> >
> > Under the skcipher interface, if both the outer and inner alg are async,
> > there should not be any problem right? Currently I do not see any
> > ex
with expected results. The test vectors are so chosen
as to exercise the scatter-gather list to the maximum allowable limit
within the framework.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@
This patch introduces the assembly routine to do a by8 AES CBC
encryption in support of the AES CBC multi-buffer implementation.
It encrypts 8 data streams of the same key size simultaneously.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey
-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/Makefile| 1 +
arch/x86/crypto/aes-cbc-mb/Makefile | 22 +
arch/x86/crypto/aes-cbc-mb/
completed state.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c | 146
arch/x86/crypto/aes-cbc-mb/m
<mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h| 97 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h| 132
arch/x86
multi-buffer encryption build
support.
For an introduction to the multi-buffer implementation, please see
http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey
feature check to make sure SSE is supported
2. Fix up unloading of aes-cbc-mb module to properly free memory
Megha Dey (7):
crypto: Multi-buffer encryption infrastructure support
crypto: AES CBC multi-buffer data structures
crypto: AES CBC multi-buffer scheduler
crypto: AES CBC by8
da...@davemloft.net;
> linux-crypto@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH V6 5/7] crypto: AES CBC multi-buffer glue code
>
> On Tue, Jul 18, 2017 at 06:18:59PM -0700, Megha Dey wrote:
> >
> > > >> +/*
> > > >> + * CR
On Tue, 2017-07-18 at 17:52 -0700, Tim Chen wrote:
> On 07/17/2017 10:41 PM, Herbert Xu wrote:
> > On Tue, Jun 27, 2017 at 05:26:13PM -0700, Megha Dey wrote:
> >>
> >> +static void completion_callback(struct mcryptd_skcipher_request_ctx *rctx,
> >> +
Hi Herbert,
Do you want any other changes to be made to this patchset?
Thanks,
Megha
On Tue, 2017-06-27 at 17:26 -0700, Megha Dey wrote:
> In this patch series, we introduce AES CBC encryption that is parallelized on
> x86_64 cpu with XMM registers. The multi-buffer technique encrypt
completed state.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c | 146
arch/x86/crypto/aes-cbc-mb/m
with expected results. The test vectors are so chosen
as to exercise the scatter-gather list to the maximum allowable limit
within the framework.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@
For more robust testing of AES CBC multibuffer support, additional
test vectors have been added to the AES CBC encrypt/decrypt
test case.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim C
<mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h| 97 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h| 132
arch/x86
-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/Makefile| 1 +
arch/x86/crypto/aes-cbc-mb/Makefile | 22 +
arch/x86/crypto/aes-cbc-mb/
This patch introduces the assembly routine to do a by8 AES CBC
encryption in support of the AES CBC multi-buffer implementation.
It encrypts 8 data streams of the same key size simultaneously.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey
multi-buffer encryption build
support.
For an introduction to the multi-buffer implementation, please see
http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey
free memory
Megha Dey (7):
crypto: Multi-buffer encryption infrastructure support
crypto: AES CBC multi-buffer data structures
crypto: AES CBC multi-buffer scheduler
crypto: AES CBC by8 encryption
crypto: AES CBC multi-buffer glue code
crypto: AES vectors for AES CBC multibuffer
On Mon, 2017-04-24 at 17:00 +0800, Herbert Xu wrote:
> On Thu, Apr 20, 2017 at 01:50:34PM -0700, Megha Dey wrote:
> >
> > +static int simd_skcipher_decrypt_mb(struct skcipher_request *req)
> > +{
> > + struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
> >
-buffer encryption build
support.
For an introduction to the multi-buffer implementation, please see
http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey
<mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h| 97 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h| 132
arch/x86
completed state.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c | 146
arch/x86/crypto/aes-cbc-mb/m
For more robust testing of AES CBC multibuffer support, additional
test vectors have been added to the AES CBC encrypt/decrypt
test case.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim C
-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/Makefile| 1 +
arch/x86/crypto/aes-cbc-mb/Makefile | 22 +
arch/x86/crypto/aes-cbc-mb/
with expected results. The test vectors are so chosen
as to exercise the scatter-gather list to the maximum allowable limit
within the framework.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Acked-by: Tim Chen <tim.c.c...@
This patch introduces the assembly routine to do a by8 AES CBC encryption
in support of the AES CBC multi-buffer implementation.
It encrypts 8 data streams of the same key size simultaneously.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey
. Update cpu feature check to make sure SSE is supported
2. Fix up unloading of aes-cbc-mb module to properly free memory
Megha Dey (7):
crypto: Multi-buffer encryption infrastructure support
crypto: AES CBC multi-buffer data structures
crypto: AES CBC multi-buffer scheduler
crypto: AES CBC by8
kernel, can you please use the lastest and let
me know if you still see this issue?
Also can you give more info on the test case? Does it issue single
request or multiple requests?
Thanks,
Megha
On Wed, 2016-09-28 at 10:58 -0700, Megha Dey wrote:
> Hi Stephan,
>
> Could you give me more info
Hi Stephan,
Could you give me more info on how I could reproduce this issue on my
end?
Also was this issue there all along? Which is the first kernel version
where you see this?
Thanks,
Megha
On Mon, 2016-09-26 at 19:32 +0200, Stephan Mueller wrote:
> Am Freitag, 26. August 2016, 03:15:06 CEST
t;mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Signed-off-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S | 775
1 file changed, 775 insertions(+)
create mode 100644 arch/x86/crypto/aes-cbc-m
-cbc-mb module to properly free memory
Megha Dey (1):
crypto: Multi-buffer encryption infrastructure support
Tim Chen (6):
crypto: AES CBC multi-buffer data structures
crypto: AES CBC multi-buffer scheduler
crypto: AES CBC by8 encryption
crypto: AES CBC multi-buffer glue code
crypto: AES
y code.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Signed-off-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h| 97 +
arch/x86/crypto/aes-cbc-mb/a
t call to submit
always returns the oldest job in a completed state.
Originally-by: Chandramouli Narayanan <mouli_7...@yahoo.com>
Signed-off-by: Megha Dey <megha@linux.intel.com>
Signed-off-by: Tim Chen <tim.c.c...@linux.intel.com>
---
arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_ini
On Thu, 2016-06-30 at 11:00 +0800, Herbert Xu wrote:
> On Wed, Jun 29, 2016 at 10:45:56AM -0700, Megha Dey wrote:
> > I tested the latest cryptodev tree on my haswell machine and this is
> > what I see:
> > [ 40.402834] modprobe tcrypt mode=422
> > [ 40.403105] t
I tested the latest cryptodev tree on my haswell machine and this is
what I see:
[ 40.402834] modprobe tcrypt mode=422
[ 40.403105] testing speed of multibuffer sha1 (sha1_mb)
[ 40.403108] test 0 ( 16 byte blocks, 16 bytes per update, 1
updates): 32271 cycles/operation, 252
From: Megha Dey <megha@linux.intel.com>
This patch introduces the data structures and prototypes of functions
needed for computing SHA512 hash using multi-buffer. Included are the
structures of the multi-buffer SHA512 job, job scheduler in C and x86
assembly.
Signed-off-by: Megha Dey
From: Megha Dey <megha@linux.intel.com>
This patch introduces the routines used to submit and flush buffers
belonging to SHA512 crypto jobs to the SHA512 multibuffer algorithm.
It is implemented mostly in assembly optimized with AVX2 instructions.
Signed-off-by: Megha Dey
From: Megha Dey <megha@linux.intel.com>
This patch introduces the multi-buffer job manager which is responsible
for submitting scatter-gather buffers from several SHA512 jobs to the
multi-buffer algorithm. It also contains the flush routine that's called
by the crypto daemon to co
From: Megha Dey <megha@linux.intel.com>
Add a new mode to calculate the speed of the sha512_mb algorithm
Signed-off-by: Megha Dey <megha@linux.intel.com>
Reviewed-by: Fenghua Yu <fenghua...@intel.com>
Reviewed-by: Tim Chen <tim.c.c...@linux.intel.com>
---
cry
From: Megha Dey <megha@linux.intel.com>
Add the config CRYPTO_SHA512_MB which will enable the computation
using the SHA512 multi-buffer algorithm.
Signed-off-by: Megha Dey <megha@linux.intel.com>
Reviewed-by: Fenghua Yu <fenghua...@intel.com>
Reviewed-by:
From: Megha Dey <megha@linux.intel.com>
This patch introduces the assembly routines to do SHA512 computation on
buffers belonging to several jobs at once. The assembly routines are
optimized with AVX2 instructions that have 4 data lanes and using AVX2
registers.
Signed-off-by: Meg
From: Megha Dey <megha@linux.intel.com>
In this patch series, we introduce the multi-buffer crypto algorithm on
x86_64 and apply it to SHA512 hash computation. The multi-buffer technique
takes advantage of the 8 data lanes in the AVX2 registers and allows
computation to be performed o
Add the config CRYPTO_SHA256_MB which will enable the computation using the
SHA256 multi-buffer algorithm.
Signed-off-by: Megha Dey <megha@linux.intel.com>
Reviewed-by: Fenghua Yu <fenghua...@intel.com>
Reviewed-by: Tim Chen <tim.c.c...@linux.intel.com>
---
c
the deadline of maximum latency of a SHA256 crypto job.
The SHA256 multi-buffer crypto algorithm is defined and initialized in
this patch.
Signed-off-by: Megha Dey <megha@linux.intel.com>
Reviewed-by: Fenghua Yu <fenghua...@intel.com>
Reviewed-by: Tim Chen <tim.c.c...@linux.intel.com
This patch introduces the data structures and prototypes of
functions needed for computing SHA256 hash using multi-buffer.
Included are the structures of the multi-buffer SHA256 job,
job scheduler in C and x86 assembly.
Signed-off-by: Megha Dey <megha@linux.intel.com>
Reviewed-by: Feng
From: Megha Dey <megha@linux.intel.com>
Until now, there was only support for the SHA1 multibuffer algorithm.
Hence, there was just one sha-mb folder. Now, with the introduction of
the SHA256 multi-buffer algorithm , it is logical to name the existing
folder as sha1-mb.
Signed-off-by:
This patch introduces the assembly routines to do SHA256 computation
on buffers belonging to several jobs at once. The assembly routines
are optimized with AVX2 instructions that have 8 data lanes and using
AVX2 registers.
Signed-off-by: Megha Dey <megha@linux.intel.com>
Reviewed-by: F
From: Megha Dey <megha@linux.intel.com>
The existing test suite to calculate the speed of the SHA algorithms
assumes serial (single buffer)) computation of data. With the SHA
multibuffer algorithms, we work on 8 lanes of data in parallel. Hence,
the need to introduce a new test
This patch introduces the routines used to submit and flush buffers
belonging to SHA256 crypto jobs to the SHA256 multibuffer algorithm. It
is implemented mostly in assembly optimized with AVX2 instructions.
Signed-off-by: Megha Dey <megha@linux.intel.com>
Reviewed-by: Fenghua Yu &l
From: Megha Dey <megha@linux.intel.com>
In this patch series, we introduce the multi-buffer crypto algorithm on
x86_64 and apply it to SHA256 hash computation. The multi-buffer technique
takes advantage of the 8 data lanes in the AVX2 registers and allows
computation to be performed o
From: Megha Dey <megha@linux.intel.com>
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm. This patch introduces
a
From: Megha Dey <megha@linux.intel.com>
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm. This patch introduces
a
From: Megha Dey <megha@linux.intel.com>
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm. This patch introduces
a
From: Megha Dey <megha@linux.intel.com>
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm. This patch introduces
a
From: Megha Dey <megha@linux.intel.com>
Currently there are several checkpatch warnings in the sha1_mb.c file:
'WARNING: line over 80 characters' in the sha1_mb.c file. Also, the
syntax of some multi-line comments are not correct. This patch fixes
these issues.
Signed-off-by: Meg
From: Megha Dey <megha@linux.intel.com>
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm. This patch introduces
a
From: Megha Dey <megha@linux.intel.com>
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm.
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
This patch introduces a
On Thu, 2016-06-02 at 18:33 +0800, Herbert Xu wrote:
> On Tue, May 31, 2016 at 02:42:21PM -0700, Megha Dey wrote:
> >
> > @@ -416,8 +421,8 @@ static void mcryptd_hash_finup(struct
> > crypto_async_request *req_async, int err)
> >
> > if (unlikely(err == -E
From: Megha Dey <megha@linux.intel.com>
Currently there are several checkpatch warnings in the sha1_mb.c file:
'WARNING: line over 80 characters' in the sha1_mb.c file. Also, the
syntax of some multi-line comments are not correct. This patch fixes
these issues.
Signed-off-by: Meg
From: Megha Dey <megha@linux.intel.com>
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm. This patch introduces
a
From: Megha Dey <megha@linux.intel.com>
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm.
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
This patch introduces a
On Tue, 2016-05-31 at 16:13 +0800, Herbert Xu wrote:
> On Thu, May 19, 2016 at 05:43:04PM -0700, Megha Dey wrote:
> > From: Megha Dey <megha@linux.intel.com>
> >
> > Currently there are several checkpatch warnings in the sha1_mb.c file:
> > 'WARNING: line ove
From: Megha Dey <megha@linux.intel.com>
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm. This patch introduces
a
From: Megha Dey <megha@linux.intel.com>
Currently there are several checkpatch warnings in the sha1_mb.c file:
'WARNING: line over 80 characters' in the sha1_mb.c file. Also, the
syntax of some multi-line comments are not correct. This patch fixes
these issues.
Signed-off-by: Meg
On Mon, 2016-05-16 at 16:46 -0500, Josh Poimboeuf wrote:
> On Mon, May 16, 2016 at 02:39:06PM -0700, Megha Dey wrote:
> > On Mon, 2016-05-16 at 15:16 -0500, Josh Poimboeuf wrote:
> > > On Mon, May 16, 2016 at 11:31:12AM -0700, Megha Dey wrote:
> > > > On Mon, 2
On Mon, 2016-05-16 at 15:16 -0500, Josh Poimboeuf wrote:
> On Mon, May 16, 2016 at 11:31:12AM -0700, Megha Dey wrote:
> > On Mon, 2016-05-16 at 09:44 -0500, Josh Poimboeuf wrote:
> > > On Fri, May 13, 2016 at 10:32:26AM -0700, Megha Dey wrote:
> > > > On Fri, 2016-05-
On Mon, 2016-05-16 at 09:44 -0500, Josh Poimboeuf wrote:
> On Fri, May 13, 2016 at 10:32:26AM -0700, Megha Dey wrote:
> > On Fri, 2016-05-13 at 07:51 +0200, Ingo Molnar wrote:
> > > * Herbert Xu <herb...@gondor.apana.org.au> wrote:
> > >
> > > > On Thu
On Fri, 2016-05-13 at 07:51 +0200, Ingo Molnar wrote:
> * Herbert Xu <herb...@gondor.apana.org.au> wrote:
>
> > On Thu, May 12, 2016 at 04:31:06PM -0700, Megha Dey wrote:
> > > Hi,
> > >
> > > When booting latest kernel with the CONFIG_CR
Hi,
When booting latest kernel with the CONFIG_CRYPTO_SHA1_MB enabled, I
observe a panic.
After having a quick look, on reverting the following patches, I am able
to complete the booting process.
aec4d0e301f17bb143341c82cc44685b8af0b945
8691ccd764f9ecc69a6812dfe76214c86ac9ba06
From: Megha Dey <megha@intel.com>
This patch introduces the routines used to submit and flush buffers
belonging to SHA256 crypto jobs to the SHA256 multibuffer algorithm. It
is implemented mostly in assembly optimized with AVX2 instructions.
Signed-off-by: Megha Dey
From: Megha Dey <megha@linux.intel.com>
Until now, there was only support for the SHA1 multibuffer algorithm.
Hence, there was just one sha-mb folder. Now, with the introduction of
the SHA256 multi-buffer algorithm , it is logical to name the existing
folder as sha1-mb.
Signed-off-by:
From: Megha Dey <megha@linux.intel.com>
Add the config CRYPTO_SHA512_MB which will enable the computation
using the SHA512 multi-buffer algorithm.
Signed-off-by: Megha Dey <megha@linux.intel.com>
Reviewed-by: Fenghua Yu <fenghua...@intel.com>
Reviewed-by:
From: Megha Dey <megha@linux.intel.com>
This patch introduces the routines used to submit and flush buffers
belonging to SHA512 crypto jobs to the SHA512 multibuffer algorithm.
It is implemented mostly in assembly optimized with AVX2 instructions.
Signed-off-by: Megha Dey
From: Megha Dey <megha@intel.com>
This patch introduces the data structures and prototypes of
functions needed for computing SHA256 hash using multi-buffer.
Included are the structures of the multi-buffer SHA256 job,
job scheduler in C and x86 assembly.
Signed-off-by: Megha Dey
From: Megha Dey <megha@intel.com>
This patch introduces the multi-buffer job manager which is responsible for
submitting scatter-gather buffers from several SHA256 jobs to the
multi-buffer algorithm. It also contains the flush routine to that's
called by the crypto daemon to complete t
From: Megha Dey <megha@linux.intel.com>
This patch introduces the data structures and prototypes of functions
needed for computing SHA512 hash using multi-buffer. Included are the
structures of the multi-buffer SHA512 job, job scheduler in C and x86
assembly.
Signed-off-by: Megha Dey
From: Megha Dey <megha@linux.intel.com>
This patch introduces the assembly routines to do SHA512 computation on
buffers belonging to several jobs at once. The assembly routines are
optimized with AVX2 instructions that have 4 data lanes and using AVX2
registers.
Signed-off-by: Meg
From: Megha Dey <megha@linux.intel.com>
This patch introduces the multi-buffer job manager which is responsible
for submitting scatter-gather buffers from several SHA512 jobs to the
multi-buffer algorithm. It also contains the flush routine that's called
by the crypto daemon to co
From: Megha Dey <megha@linux.intel.com>
Add a new mode to calculate the speed of the sha512_mb algorithm
Signed-off-by: Megha Dey <megha@linux.intel.com>
Reviewed-by: Fenghua Yu <fenghua...@intel.com>
Reviewed-by: Tim Chen <tim.c.c...@linux.intel.com>
---
crypt
From: Megha Dey <megha@intel.com>
The existing test suite to calculate the speed of the SHA algorithms
assumes serial (single buffer)) computation of data. With the SHA
multibuffer algorithms, we work on 8 lanes of data in parallel. Hence, the
need to introduce a new test suite to cal
From: Megha Dey <megha@intel.com>
This patch introduces the assembly routines to do SHA256 computation
on buffers belonging to several jobs at once. The assembly routines
are optimized with AVX2 instructions that have 8 data lanes and using
AVX2 registers.
Signed-off-by: Megha Dey
From: Megha Dey <megha@linux.intel.com>
In this patch series, we introduce the multi-buffer crypto algorithm on
x86_64 and apply it to SHA256 hash computation. The multi-buffer technique
takes advantage of the 8 data lanes in the AVX2 registers and allows
computation to be performed o
From: Megha Dey <megha@linux.intel.com>
The _args_digest is defined as _args+_digest, both of which are the first
members of 2 separate structures, effectively yielding _args_digest to have
a value of zero. Thus, no errors have spawned yet due to this. To ensure
sanity, adding the m
99 matches
Mail list logo
