[RFC PATCH v2 4/7] crypto: x86/aesni-xctr: Add accelerated implementation of XCTR

[Eric Biggers]

On Thu, Feb 10, 2022 at 11:28:09PM +0000, Nathan Huckleberry wrote:
> diff --git a/arch/x86/crypto/aes_xctrby8_avx-x86_64.S b/arch/x86/crypto/aes_xctrby8_avx-x86_64.S
> new file mode 100644
> index 000000000000..53d70cab9474
> --- /dev/null
> +++ b/arch/x86/crypto/aes_xctrby8_avx-x86_64.S
> @@ -0,0 +1,529 @@
> +/* SPDX-License-Identifier: GPL-2.0-only OR BSD-3-Clause */
> +/*
> + * AES XCTR mode by8 optimization with AVX instructions. (x86_64)
> + *
> + * Copyright(c) 2014 Intel Corporation.
> + *
> + * Contact Information:
> + * James Guilford <james.guilford at intel.com>
> + * Sean Gulley <sean.m.gulley at intel.com>
> + * Chandramouli Narayanan <mouli at linux.intel.com>
> + */
> +/*
> + * Implement AES XCTR mode with AVX instructions. This code is a modified
> + * version of the Linux kernel's AES CTR by8 implementation.
> + *
> + * This is AES128/192/256 XCTR mode optimization implementation. It requires
> + * the support of Intel(R) AESNI and AVX instructions.
> + *
> + * This work was inspired by the AES XCTR mode optimization published
> + * in Intel Optimized IPSEC Cryptographic library.
> + * Additional information on it can be found at:
> + *    https://github.com/intel/intel-ipsec-mb
> + */

So I haven't looked at this closely yet, but one thing I noticed is that this
file is pretty long, and it's almost identical to aes_ctrby8_avx-x86_64.S.
Perhaps it would make sense to add XCTR support to that file rather than
duplicating most of it into this new file?  You could add an is_xctr argument to
the macros to allow making parts conditional on CTR or XCTR when needed.

- Eric