Messages in this thread | | | Subject | Re: [RFC V1 0/7] Introduce AVX512 optimized crypto algorithms | From | "Dey, Megha" <> | Date | Sat, 16 Jan 2021 10:35:16 -0800 |
| |
Hi Ard,
On 1/16/2021 8:52 AM, Ard Biesheuvel wrote: > On Mon, 28 Dec 2020 at 20:11, Dey, Megha <megha.dey@intel.com> 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!
| |