From: Megha Dey <megha.dey@linux.intel.com>
To: herbert@gondor.apana.org.au
Cc: tim.c.chen@linux.intel.com, davem@davemloft.net,
linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
megha.dey@intel.com, Megha Dey <megha.dey@linux.intel.com>
Subject: [Patch V5 0/7] crypto: AES CBC multibuffer implementation
Date: Thu, 20 Apr 2017 13:50:33 -0700 [thread overview]
Message-ID: <1492721440-3698-1-git-send-email-megha.dey@linux.intel.com> (raw)
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
existing AESNI Intel CBC implementation which can already parallelize decryption
even for a single data stream.
Please see the multi-buffer whitepaper for details of the technique:
http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html
It is important that any driver uses this algorithm properly for scenarios
where we have many data streams that can fill up the data lanes most of the
time. It shouldn't be used when only a single data stream is expected mostly.
Otherwise we may incur extra delays when we have frequent gaps in data lanes,
causing us to wait till data come in to fill the data lanes before initiating
encryption. We may have to wait for flush operations to commence when no new
data come in after some wait time. However we keep this extra delay to a
minimum by opportunistically flushing the unfinished jobs if crypto daemon is
the only active task running on a cpu.
By using this technique, we saw a throughput increase of up to 5.7x under
optimal conditions when we have fully loaded encryption jobs filling up all
the data lanes.
Change Log:
v5
1. Use an async implementation of the inner algorithm instead of sync and use
the latest skcipher interface instead of the older blkcipher interface.
(we have picked up this work after a while)
v4
1. Make the decrypt path also use ablkcpher walk.
http://lkml.iu.edu/hypermail/linux/kernel/1512.0/01807.html
v3
1. Use 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 (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 testing
crypto: AES CBC multi-buffer tcrypt
arch/x86/crypto/Makefile | 1 +
arch/x86/crypto/aes-cbc-mb/Makefile | 22 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S | 775 ++++++++++
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c | 737 ++++++++++
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/crypto/aes-cbc-mb/aes_mb_mgr_init.c | 146 ++
arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S | 271 ++++
arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S | 223 +++
arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S | 417 ++++++
arch/x86/crypto/aes-cbc-mb/reg_sizes.S | 126 ++
crypto/Kconfig | 15 +
crypto/mcryptd.c | 298 ++++
crypto/simd.c | 164 +++
crypto/tcrypt.c | 257 +++-
crypto/testmgr.c | 707 +++++++++
crypto/testmgr.h | 1496 ++++++++++++++++++++
include/crypto/internal/simd.h | 3 +
include/crypto/mcryptd.h | 35 +
19 files changed, 5921 insertions(+), 1 deletion(-)
create mode 100644 arch/x86/crypto/aes-cbc-mb/Makefile
create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S
create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c
create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h
create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c
create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S
create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S
create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S
create mode 100644 arch/x86/crypto/aes-cbc-mb/reg_sizes.S
--
1.9.1
next reply other threads:[~2017-04-20 20:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 20:50 Megha Dey [this message]
2017-04-20 20:50 ` [Patch V5 1/7] crypto: Multi-buffer encryption infrastructure support Megha Dey
2017-04-21 0:19 ` kbuild test robot
2017-04-21 3:02 ` kbuild test robot
2017-04-24 9:00 ` Herbert Xu
2017-06-08 19:52 ` Megha Dey
2017-06-23 8:32 ` Herbert Xu
2017-04-20 20:50 ` [Patch V5 2/7] crypto: AES CBC multi-buffer data structures Megha Dey
2017-04-20 20:50 ` [Patch V5 3/7] crypto: AES CBC multi-buffer scheduler Megha Dey
2017-04-20 20:50 ` [Patch V5 4/7] crypto: AES CBC by8 encryption Megha Dey
2017-04-20 20:50 ` [Patch V5 5/7] crypto: AES CBC multi-buffer glue code Megha Dey
2017-04-20 20:50 ` [Patch V5 6/7] crypto: AES vectors for AES CBC multibuffer testing Megha Dey
2017-04-20 20:50 ` [Patch V5 7/7] crypto: AES CBC multi-buffer tcrypt Megha Dey
2017-04-21 0:54 ` kbuild test robot
2017-04-21 1:56 ` kbuild test robot
-- strict thread matches above, loose matches on Subject: below --
2016-09-26 17:27 [PATCH v5 0/7] crypto: AES CBC multibuffer implementation Megha Dey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1492721440-3698-1-git-send-email-megha.dey@linux.intel.com \
--to=megha.dey@linux.intel.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=megha.dey@intel.com \
--cc=tim.c.chen@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).