| Message ID | 20221214171957.2833419-1-ardb@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | crypto: Accelerated GCM for IPSec on ARM/arm64 | expand |
On Wed, 14 Dec 2022 at 18:20, Ard Biesheuvel <ardb@kernel.org> wrote: > > This is a v2 as patch #1 was sent out in isolation a couple of days ago. > > As it turns out, we can get ~10% speedup for RFC4106 on arm64 > (Cortex-A53) by giving it the same treatment as ARM, i.e., avoid the > generic template and implement RFC4106 encapsulation directly in the > driver > > Patch #3 adds larger key sizes to the tcrypt benchmark for RFC4106 > > Patch #4 fixes some prose on AEAD that turned out to be inaccurate. > > Changes since v1: > - minor tweaks to the asm code in patch #1, one of which to fix a Clang > build error > > Note: patch #1 depends on the softirq context patches for kernel mode > NEON I sent out last week. More specifically, this implements a sync > AEAD that does not implement a !simd fallback, as AEADs are not callable > in hard IRQ context anyway. > These prerequisite changes have now been queued up in the ARM tree. Note that these are runtime prerequisites only so I think this series can be safely merged as well, as I don't think anyone builds cryptodev for 32-bit ARM and tests it on 64-bit hardware (which is the only hardware that implements the AES instructions that patch #1 relies on) > Cc: Eric Biggers <ebiggers@kernel.org> > Cc: Herbert Xu <herbert@gondor.apana.org.au> > > Ard Biesheuvel (4): > crypto: arm/ghash - implement fused AES/GHASH version of AES-GCM > crypto: arm64/gcm - add RFC4106 support > crypto: tcrypt - include larger key sizes in RFC4106 benchmark > crypto: aead - fix inaccurate documentation > > arch/arm/crypto/Kconfig | 2 + > arch/arm/crypto/ghash-ce-core.S | 382 +++++++++++++++++- > arch/arm/crypto/ghash-ce-glue.c | 424 +++++++++++++++++++- > arch/arm64/crypto/ghash-ce-glue.c | 145 +++++-- > crypto/tcrypt.c | 8 +- > crypto/tcrypt.h | 2 +- > include/crypto/aead.h | 20 +- > 7 files changed, 913 insertions(+), 70 deletions(-) > > -- > 2.35.1 >
On Fri, Jan 13, 2023 at 05:00:59PM +0100, Ard Biesheuvel wrote: > > These prerequisite changes have now been queued up in the ARM tree. > > Note that these are runtime prerequisites only so I think this series > can be safely merged as well, as I don't think anyone builds cryptodev > for 32-bit ARM and tests it on 64-bit hardware (which is the only > hardware that implements the AES instructions that patch #1 relies on) Acked-by: Herbert Xu <herbert@gondor.apana.org.au> I don't have any objections for merging this through the arm tree. Thanks,
On Mon, 16 Jan 2023 at 04:29, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > On Fri, Jan 13, 2023 at 05:00:59PM +0100, Ard Biesheuvel wrote: > > > > These prerequisite changes have now been queued up in the ARM tree. > > > > Note that these are runtime prerequisites only so I think this series > > can be safely merged as well, as I don't think anyone builds cryptodev > > for 32-bit ARM and tests it on 64-bit hardware (which is the only > > hardware that implements the AES instructions that patch #1 relies on) > > Acked-by: Herbert Xu <herbert@gondor.apana.org.au> > > I don't have any objections for merging this through the arm tree. > Thanks. Will you be taking the rest of the series? (patches #2 - #4). Or we might defer this to v6.4 entirely it if makes things easier. (The other changes really shouldn't go through the ARM tree)
On Mon, Jan 16, 2023 at 08:40:09AM +0100, Ard Biesheuvel wrote: > > Will you be taking the rest of the series? (patches #2 - #4). Or we > might defer this to v6.4 entirely it if makes things easier. (The > other changes really shouldn't go through the ARM tree) I had assumed they were dependent. But they do seem to make sense on their own so yes I can certainly take patches 2-4. Cheers,
On Mon, 16 Jan 2023 at 09:06, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > On Mon, Jan 16, 2023 at 08:40:09AM +0100, Ard Biesheuvel wrote: > > > > Will you be taking the rest of the series? (patches #2 - #4). Or we > > might defer this to v6.4 entirely it if makes things easier. (The > > other changes really shouldn't go through the ARM tree) > > I had assumed they were dependent. But they do seem to make sense > on their own so yes I can certainly take patches 2-4. > Excellent, thanks. Patch #1 has been picked up by Russell, so please pick up the rest.
On Wed, Dec 14, 2022 at 06:19:53PM +0100, Ard Biesheuvel wrote: > This is a v2 as patch #1 was sent out in isolation a couple of days ago. > > As it turns out, we can get ~10% speedup for RFC4106 on arm64 > (Cortex-A53) by giving it the same treatment as ARM, i.e., avoid the > generic template and implement RFC4106 encapsulation directly in the > driver > > Patch #3 adds larger key sizes to the tcrypt benchmark for RFC4106 > > Patch #4 fixes some prose on AEAD that turned out to be inaccurate. > > Changes since v1: > - minor tweaks to the asm code in patch #1, one of which to fix a Clang > build error > > Note: patch #1 depends on the softirq context patches for kernel mode > NEON I sent out last week. More specifically, this implements a sync > AEAD that does not implement a !simd fallback, as AEADs are not callable > in hard IRQ context anyway. > > Cc: Eric Biggers <ebiggers@kernel.org> > Cc: Herbert Xu <herbert@gondor.apana.org.au> > > Ard Biesheuvel (4): > crypto: arm/ghash - implement fused AES/GHASH version of AES-GCM > crypto: arm64/gcm - add RFC4106 support > crypto: tcrypt - include larger key sizes in RFC4106 benchmark > crypto: aead - fix inaccurate documentation > > arch/arm/crypto/Kconfig | 2 + > arch/arm/crypto/ghash-ce-core.S | 382 +++++++++++++++++- > arch/arm/crypto/ghash-ce-glue.c | 424 +++++++++++++++++++- > arch/arm64/crypto/ghash-ce-glue.c | 145 +++++-- > crypto/tcrypt.c | 8 +- > crypto/tcrypt.h | 2 +- > include/crypto/aead.h | 20 +- > 7 files changed, 913 insertions(+), 70 deletions(-) > > -- > 2.35.1 Patches 2-4 applied. Thanks.