Re: Cryptsetup and hardware accelerated AES-XTS

On Sunday, July 21st, 2024 at 4:58 PM, Eric Biggers <[email protected]> wrote:

> 
> 
> On Sun, Jul 21, 2024 at 09:14:02AM +0000, Maxim Fomin wrote:
> 
> > On Saturday, July 20th, 2024 at 6:36 PM, Eric Biggers [email protected] wrote:
> > 
> > > On Sat, Jul 20, 2024 at 12:15:23PM +0000, Maxim Fomin wrote:
> > > 
> > > > Hi!
> > > > 
> > > > Recently linux kernel got[1] faster AES-XTS on modern x86_64 CPUs thanks to VAES and AVX-10/512. I decided to dig deeper into this issue and found the article[2] from 2020 stating that dm-crypt can be configured to use faster (synchronous and hardware accelerated) algorithms with 'capi:' prefix. Can cryptsetup be configured to ask dm-crypt to use hardware accelerated algorithms?
> > > > 
> > > > [1] https://lore.kernel.org/lkml/[email protected]/T/#m83293b2699f9a5da04fc5780ee402191dace3926
> > > > 
> > > > [2] https://blog.cloudflare.com/speeding-up-linux-disk-encryption/
> > > > 
> > > > Best regards,
> > > > Maxim
> > > 
> > > You don't need to use "capi:". Just make sure CONFIG_CRYPTO_AES_NI_INTEL=y is
> > > enabled in your kernel (which it already should have been since it was needed
> > > for AES-NI acceleration before), and the new code will be used automatically if
> > > your CPU supports it.
> > > 
> > > - Eric
> > 
> > I have heard that on some Intel CPUs AVX-512 is ignored (although it is
> > supported) because of downclocking. I have rocketlake i5-11600K. How I can
> > check which algorithm is actually used? How I can force cryptsetup/dm-crypt to
> > enable AVX-512 version if it is not used?
> 
> 
> The way to tell which AES-XTS implementation is used by default on a particular
> system is to check /proc/crypto for which "xts(aes)" has the highest priority.

Does the priority property takes into account deprioritization of Ice Lake and Tiger Lake?
Btw, actual function can be noticed in 'perf' command output, which in my case confirms that indeed vaes-avx10-512 version is used.

> There is a way to change algorithm priorities to override the default, but there
> isn't much reason to think that people would be able to make a better choice
> than the kernel's default.

Default choice may be problematic because it is applied in every case and does not take into account option to disable downclocking and thermal limit on actual machine. Some BIOS versions allow to disable downclocking (called AVX512 ratio offset or similar). If this option is available and thermal limit is not applicable, then default kernel policy means some potential CPU frequency is lost. 

> The implementation that uses 512-bit vectors
> (xts-aes-vaes-avx10_512) is only deprioritized on Ice Lake and Tiger Lake, so it
> won't happen on your system anyway as it uses Rocket Lake. On CPUs where the
> deprioritization of xts-aes-vaes-avx10_512 does happen, there is a reason for
> it, and it is only 512-bit vectors that are disabled, not AVX-512 entirely.
> 
> - Eric

Thanks for clarification. Just for reference - this setting currently resides at arch/x86/crypto/aesni-intel_glue.c and can be moved somewhere else as is written in the patch.

Best regards,
Maxim