Re: [PATCH v2 6/6] crypto: x86/aes-xts - wire up VAES + AVX10/512 implementation

Dave Hansen
2024-04-04T23:53:13Z

On 4/4/24 16:36, Eric Biggers wrote:
> 1. Never use zmm registers.
...
> 4. Keep the proposed policy as the default behavior, but allow it to be
> overridden on the kernel command line. This would be a bit more flexible;
> however, most people don't change defaults anyway.
>
> When you write "Some folks will also surely disagree with the kernel policy
> implemented here", are there any specific concerns that you anticipate?

Some people care less about the frequency throttling and only care about
max performance _using_ AVX512.

> Note that Intel has acknowledged the zmm downclocking issues on Ice
> Lake and suggested that using ymm registers instead would be
> reasonable:>
https://lore.kernel.org/linux-crypto/e8ce1146-3952-6977-1d0e-a22758e58914@intel.com/
>
> If there is really a controversy, my vote is that for now we just go with option
> (1), i.e. drop this patch from the series. We can reconsider the issue when a
> CPU is released with better 512-bit support.

(1) is fine with me.

(4) would also be fine. But I don't think it absolutely _has_ to be a
boot-time switch. What prevents you from registering, say,
"xts-aes-vaes-avx10" and then doing:

if (avx512_is_desired())
xts-aes-vaes-avx10_512(...);
else
xts-aes-vaes-avx10_256(...);

at runtime?

Where avx512_is_desired() can be changed willy-nilly, either with a
command-line parameter or runtime knob. Sure, the performance might
change versus what was measured, but I don't think that's a deal breaker.

Then if folks want to do fancy benchmarks or model/family checks or
whatever, they can do it in userspace at runtime.