DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 735B8606A31C
Message-ID: <6ce2344c-f6b5-4051-87b0-88a1c258a6d3@mandelbit.com>
Date: Mon, 9 Nov 2026 16:47:05 +0100
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Eric Biggers <ebiggers@kernel.org>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
From: Antonio Quartulli <antonio@mandelbit.com>
Subject: lib/crypto: AES-GCM x86 arch hooks: any plan?
Organization: Mandelbit SRL
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Eric,

while working on optimising ovpn (OpenVPN data channel offload) we
prototyped what an x86 implementation of 
aes_gcm_{en,de}crypt_update_arch() would give us: ovpn calls the 
existing VAES-AVX512
GCM code directly on
linear records (AAD update, en/decrypt update and final in one FPU
section), instead of going through the crypto_aead API.

On a Ryzen 9 9950X (Zen 5), ovpn over 100G, MTU 1500, the receiver (the
bottleneck) saves ~120-127 cycles per record at every record size, i.e. the
request/scatterlist/skcipher_walk overhead:

                      Gbit/s, AES-GCM
                      crypto_aead   direct
   1 stream, 1000 B      21.34      22.86   +7.1%
   1 stream, 1500 B      29.73      31.67   +6.5%
   1 stream, 2500 B      40.78      43.13   +5.8%
   4 streams, 1500 B     28.79      30.48   +5.9%

With RX prefetching in
the NIC driver the receiver gets cheaper and the gain grows to +10.8%
(41.23 -> 45.70 Gbit/s, 1 stream). On the sending side (single packets
and UDP GSO segments) the direct path saves ~40-100 cycles per packet;
throughput there is set by the receiver.

Since the commit adding GCM to the library says the arch-optimized code
will be migrated into it, do you already have work in progress for x86?

If not, we'd be happy to help there, or to test yours on Zen 5 with ovpn
as a user.

One design question I have though: the VAES code needs the hash key
powers H^16..H^1 (and H^8..H^1 for VAES-AVX2 / AES-NI), while the x86
ghash_key only holds the PCLMUL state.

Would you rather extend struct ghash_key on x86, or have an
arch-specific part in struct aes_gcm_key that aes_gcm_preparekey()
fills when the arch code is usable?

Thanks a lot!

-- 
Antonio Quartulli

CEO and Co-Founder
Mandelbit Srl
https://www.mandelbit.com