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/[email protected]/). > > 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 [email protected]
