DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org B1C02606CD44
Message-ID: <843f872b-5afb-49f3-bfa3-1930921fd06c@mandelbit.com>
Date: Tue, 10 Nov 2026 11:21:30 +0100
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: lib/crypto: AES-GCM x86 arch hooks: any plan?
To: Eric Biggers <ebiggers@kernel.org>
Cc: Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
References: <6ce2344c-f6b5-4051-87b0-88a1c258a6d3@mandelbit.com>
 <20261109192053.GA57100@google.com>
Content-Language: en-US
From: Antonio Quartulli <antonio@mandelbit.com>
Organization: Mandelbit SRL
In-Reply-To: <20261109192053.GA57100@google.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Eric,

On 09/11/2026 20:20, Eric Biggers wrote:
> I'm planning it.  I've just been trying to get other things out of the
> way first.  If you're interested you can try to do it; just keep in mind
> it will be quite a bit of work to do properly.
> 

Thanks! Then I'll leave it to you, and I'm happy to test the series on
Zen 5 with ovpn when it's ready.

[...]

> That by itself may result in performance regressions on short messages,
> though, as each AES-GCM operation would be broken up into multiple calls
> to the arch code.  There likely will also need to be new hooks for
> one-shot AES-GCM operations to handle them efficiently.

One data point I wanted to share on this part from the ovpn prototype.

I did split its single FPU section into three (AAD update, en/decrypt
update and final, each in its own kernel_fpu_begin()/kernel_fpu_end(),
same asm otherwise) and measured the receiver, which is the bottleneck
(Ryzen 9 9950X, 100G, 1 stream):

                  one section   split      receiver cycles/record
   920 B records    34.22       33.86      1120 -> 1131 (+11)
   1420 B           45.59       44.95      1306 -> 1317 (+10)
   2420 B           55.43       54.79      1836 -> 1850 (+14)
                   (Gbit/s)

So the split costs at most ~10-14 cycles per record.
The sender showed no difference.
The receiver mostly runs in ksoftirqd, so there is no user FPU state to
save in kernel_fpu_begin().

Therefore I think most of the ~120 cycles per record the direct path
saves come from avoiding the crypto_aead request, scatterlist and walk,
not from the single FPU section: for ovpn, update-level hooks would
already get nearly all of it, as long as the C code between the calls
stays light (that part I couldn't measure).

All in all, a one-shot hook would still be welcome (although it doesn't
look super critical here).

Thanks a lot!

-- 
Antonio Quartulli

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