Re: [RFC V1 0/7] Introduce AVX512 optimized crypto algorithms

[Dey, Megha]

Hi Ard,

On 1/16/2021 8:52 AM, Ard Biesheuvel wrote:
> On Mon, 28 Dec 2020 at 20:11, Dey, Megha <megha.dey@xxxxxxxxx> wrote:
> > Hi Eric,
> >
> > On 12/21/2020 3:20 PM, Eric Biggers wrote:
> > > On Fri, Dec 18, 2020 at 01:10:57PM -0800, Megha Dey wrote:
> > > > Optimize crypto algorithms using VPCLMULQDQ and VAES AVX512 instructions
> > > > (first implemented on Intel's Icelake client and Xeon CPUs).
> > > >
> > > > These algorithms take advantage of the AVX512 registers to keep the CPU
> > > > busy and increase memory bandwidth utilization. They provide substantial
> > > > (2-10x) improvements over existing crypto algorithms when update data size
> > > > is greater than 128 bytes and do not have any significant impact when used
> > > > on small amounts of data.
> > > >
> > > > However, these algorithms may also incur a frequency penalty and cause
> > > > collateral damage to other workloads running on the same core(co-scheduled
> > > > threads). These frequency drops are also known as bin drops where 1 bin
> > > > drop is around 100MHz. With the SpecCPU and ffmpeg benchmark, a 0-1 bin
> > > > drop(0-100MHz) is observed on Icelake desktop and 0-2 bin drops (0-200Mhz)
> > > > are observed on the Icelake server.
> > > Do these new algorithms all pass the self-tests, including the fuzz tests that
> > > are enabled when CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y?
> > I had tested these algorithms with CRYPTO_MANAGER_DISABLE_TESTS=n and
> > tcrypt, not with
> > CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y (I wasn't aware this existed, my bad).
> > I see a couple of errors after enabling it and am working on fixing those.
> Hello Megha,
>
> I think the GHASH changes can be dropped (as discussed in the other
> thread), given the lack of a use case. The existing GHASH driver could
> also be removed in the future, but I don't think it needs to be part
> of this series.
Ok, I will remove the GHASH patch from the next series.
> Could you please rebase this onto the latest AES-NI changes that are
> in Herbert's tree? (as well as the ones I sent out today) They address
> some issues with indirect calls and excessive disabling of preemption,
> and your GCM and CTR changes are definitely going to be affected by
> this as well.
Yeah sure, will do, thanks for the headsup!