[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f31a9a3f-ec9a-44e1-85ae-c0e0391ff0fc@linux.ibm.com>
Date: Wed, 14 Jan 2026 13:12:20 +0100
From: Holger Dengler <dengler@...ux.ibm.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>,
"Jason A . Donenfeld" <Jason@...c4.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
linux-arm-kernel@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org,
linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
sparclinux@...r.kernel.org, x86@...nel.org,
Harald Freudenberger <freude@...ux.ibm.com>,
linux-crypto@...r.kernel.org
Subject: Re: [PATCH 15/36] lib/crypto: s390/aes: Migrate optimized code into
library
On 07/01/2026 21:34, Eric Biggers wrote:
> On Wed, Jan 07, 2026 at 08:41:02AM +0100, Holger Dengler wrote:
>> Hi Eric,
>>
>> first of all: happy New Year! ANd thanks for the series.
>>
>> On 05/01/2026 06:12, Eric Biggers wrote:
>>> Implement aes_preparekey_arch(), aes_encrypt_arch(), and
>>> aes_decrypt_arch() using the CPACF AES instructions.
>>
>> I'm not sure, it it makes sense to implement this on s390 at all. The CPACF
>> instructions cover full modes of operations and are to process more
>> than one cipher-block-size (*). For single-block operations, the performance
>> might be worth than using the generic functions. I will look into it and do
>> some performance tests. If there is a possibility to plug-in to the level
>> where the modes of operation are implemented, it would make much more sense
>> for s390.
>>
>> (*) Yes, it's a bit uncommon, but the CPACF instructions on s390 can process
>> multiple block with a single instruction call! They are so called long running
>> instructions.
>
> I'm happy to drop the CPACF single-block AES code if it's not
> worthwhile. I included it only because arch/s390/crypto/ already has
> such code. Since I'm making it so that the crypto_cipher API simply
> wraps the library API, if this code is not brought into the library it
> will effectively be dropped. You had pushed back the last time I
> proposed dropping one of the s390 optimizations, even a fairly minor one
> (https://lore.kernel.org/linux-crypto/51fc91b6-3a6e-44f7-ae93-aef0bcb48964@linux.ibm.com/).
>
> But I have no way to test or benchmark the s390 code myself. If the
> CPACF single-block AES en/decryption code isn't worthwhile, there's no
> reason to keep it, so I'll remove it.
My assumtion, that the aes single-block-operation operation is slower in CPACF
than in software, seems to be wrong. I did some measurements on different
machines and it turns out, that it is up to ~2x faster doing it in CPACF.
So, sorry for the noise. Please leave your s390 implementation as it is.
PS: I have a simple kunit test for aes (KAT and benchmark for each direction
and key-size). I'll send it in a separate reply. Feel free to pick it.
> As for AES modes, later patchsets are going to introduce
> architecture-optimized AES modes into the library, and the traditional
> crypto API for those modes will similarly be reimplemented on top of it.
> This patchset just focuses on the existing library API for key expansion
> and single block en/decryption as a first step. (As with the
> traditional API, single block en/decryption is needed as a fallback to
> handle any modes that don't have a standalone implementation.)
Ok. So we'll wait for upcoming patchsets.
--
Mit freundlichen Grüßen / Kind regards
Holger Dengler
--
IBM Systems, Linux on IBM Z Development
dengler@...ux.ibm.com
Powered by blists - more mailing lists