From: Eric Biggers <ebiggers@kernel.org>
To: Martin Willi <martin@strongswan.org>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>,
Ard Biesheuvel <ardb@kernel.org>,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH] lib/crypto: x86/chacha: Add a 16-block AVX-512 variant
Date: Sun, 4 Oct 2026 20:03:16 +0200 [thread overview]
Message-ID: <20261004180316.GE1906@quark> (raw)
In-Reply-To: <aaca79db6bd81c539b1f1698603c7249be48a7b7.camel@strongswan.org>
On Thu, Jul 23, 2026 at 01:03:50PM +0200, Martin Willi wrote:
> Hi Eric,
>
> > This is very similar to the existing chacha_8block_xor_avx512vl(), just
> > with 512-bit vectors instead of 256-bit. They even use the same CPU
> > instruction set extensions: there are actually no cases where a CPU can
> > run chacha_8block_xor_avx512vl() but not chacha_16block_xor_avx512()
> > (the choice of vector length is just going to be made by policy).
> >
> > Given that, could we consolidate these implementations?
>
> Yes, it is doable, but with some constraints:
>
> * In the 512-bit version, adding the initial state to the result uses
> a small optimization with re-broadcasting, so it differs from the
> 256-bit variant. That optimization can be applied to the 256-bit
> version for a unification, but would mean a change to it.
> * The larger part of the interleaving tail is different and will
> require separate code paths.
>
> So the net win is shared broadcasting/doubleround at the cost of some
> macro complexity. I'll give it a try.
>
> > Well, this is one of the cases where
> > cpu_has_xfeatures(XFEATURE_MASK_AVX512) was already required by the
> > existing code (since all AVX512 bits need to be enabled for any EVEX
> > coded instructions to work, even on xmm/ymm). But it was never checked,
> > and no one ever noticed. I would just continue to leave it out.
> >
> > You can also drop the check of X86_FEATURE_AVX512F, which is implied by
> > X86_FEATURE_AVX512VL and X86_FEATURE_AVX512BW already.
>
> Ok, will do so.
Hi Martin, is there any update on this?
- Eric
next prev parent reply other threads:[~2026-10-04 18:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-22 15:32 [PATCH] lib/crypto: x86/chacha: Add a 16-block AVX-512 variant Martin Willi
2026-07-22 23:24 ` Eric Biggers
2026-07-23 11:03 ` Martin Willi
2026-10-04 18:03 ` Eric Biggers [this message]
2026-10-12 9:20 ` Martin Willi
2026-08-06 1:16 ` kernel test robot
2026-08-06 6:07 ` kernel test robot
2026-08-06 7:40 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261004180316.GE1906@quark \
--to=ebiggers@kernel.org \
--cc=Jason@zx2c4.com \
--cc=ardb@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=martin@strongswan.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.