Support for Intel SHA Extensions

[jvandertil]

Unsure if this is already the case, or that this is considered too low level / not applicable.

But to improve the performance of the sha256 hashing algorithm, the Intel SHA extensions could be implemented. As described here: http://software.intel.com/en-us/articles/intel-sha-extensions

Or is this something that would have to be implemented in the Linux kernel / some other library?

[casualfish]

The linux kernel has its own SHA 256 implementation and obviously the hardware gurus keep on optimizing it.
http://lkml.indiana.edu/hypermail/linux/kernel/1303.2/04352.html
For the moment ZOL uses its own SHA256 algorithm, @behlendorf do we have the plan to take advantage of the hardware-dependent crypto part of the kernel?

[ryao]

@casualfish The generic answer to your question is no. APIs marked EXPORT_SYMBOL_GPL are unsuitable for use by the project and the shash API used to hook into the kernel's cryptography API is marked with EXPORT_SYMBOL_GPL. I suppose that it could be used anyway when ZFS is built into the kernel binary, but the fact that we cannot redistribute such binaries prevents many people hacking on ZFS from implementing that.

Looking somewhat deeper, I see that arch/x86/crypto/sha256-avx2-asm.S is dual-licensed under both the GPLv2 and 2-clause BSD licenses. It should be possible to implement our own infrastructure to decide when it should be used and use it directly, but there are bigger issues to tackle right now. I suspect that most people involved with the project are not interested in pursuing that at this time.

With that said, relying on an internal assembly API to access the Linux kernel's sha256-avx2's routine would pose a risk of pool corruption should the API change in a way that introduces a silent failure. If anyone does implement code to take advantage of the Linux kernel's sha256-avx2's routine, it would be best to copy it into the ZFS source tree. That would protect ZFS from changes to the API.

[jvandertil]

I will take a look at those components. No promises on an implementation, as my C/C++ skills are somewhat lacking...

[casualfish]

@ryao Thanks for your explanation. The license issues stop us from seeking the best again. Perhaps it's not a big performance issue now and I think what you proposed is a feasible solution.

[ryao]

@jvandertil Try to avoid importing any pools containing important data when testing your modifications until they have been reviewed. A subtle error in the checksum code could cause pool corruption.

[jvandertil]

I have been looking at this yesterday, and I am unsure what is the preferred way to approach this.

In the Linux kernel source there are a couple of dual licensed ASM files that implement components of the SHA-256 hash algorithm using SSSE3, AVX, and AVX2 (direct link to current mainline: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/x86/crypto?id=refs/tags/v3.12-rc2).
However, I'm wondering if runtime detection of CPU features (using CPUID) is the way to go, or if it is possible (or preferred) to patch the config (configure script) so we can use defines to include / exclude code that can be used at compile time.

Considering that the ZFS module will be included in the DKMS build process, using compile time checks should not be a problem. Obviously, if SSE3/AVX/AVX2 are not supported then we can fall back on the current implementation.

The Linux kernel uses the internal header file cpufeatures.h (example: http://lxr.free-electrons.com/source/arch/x86/include/asm/cpufeature.h) to determine CPU features, but I'm not sure if it is wise to use this in the sha256.c file.

[ryao]

@jvandertil Runtime detection would be better. Compile time detection would get us into trouble in situations that involve cross compilation.

[behlendorf]

@jvandertil If possible run time detection would be preferable. Not everyone uses the DKMS packages and there are sites (like LLNL) which build binaries packages in a virtual environment using an automated build farm and then deploy those packages on a variety of hardware.

[jvandertil]

Very well, I wanted to keep the number of external dependencies as low as possible. But I guess that I will need a CPUID library for the runtime detection.

[tuxoko]

Hi @jvandertil
I'm interested in this issue.
Are you still working on this?
What's your current status?

[jvandertil]

Hello @tuxoko, I haven't done much to fullfil this feature yet. I'm not that proficient in C/C++, plus it hasn't been on my priority list between finishing my MSc and work. I see you've picked up the ball on this, thanks :).

[split-n]

Is this still not interested? SHA Extension is now available since EPYC Naples and Xeon Ice Lake.

[cybojanek]

Is this still not interested? SHA Extension is now available since EPYC Naples and Xeon Ice Lake.

I'm working on this here: #12549

[mcmilk]

@jvandertil - this issue is resolved via #13741 ;-)

[behlendorf]

Thanks for commenting on this issue and linking to the PR which resolved it. Closing.