Intel QuickAssist Hit By Second Demotion In Linux 6.17 Due To Lack Of Kernel Benefit
([Linux Kernel] 36 Minutes Ago
Intel QuickAssist)
- Reference: 0001566350
- News link: https://www.phoronix.com/news/Intel-QAT-Crypto-Linux-6.17
- Source link:
A few days ago [1]the Intel QuickAssist "QAT" accelerators were demoted by FSCRYPT in the Linux 6.17 development code due to being slow and bug prone with AVX-512 showing to be much faster than leveraging the QAT accelerators in this file encryption framework. With the Linux 6.17 crypto subsystem is a second separate demotion to Intel's QAT support for kernel use.
The Intel QAT crypto driver has lowered the priority for QAT usage with the SKCIPHER and AEAD algorithms for lack of benefit with the typical kernel use-cases. The [2]patch by Intel engineer Giovanni Cabiddu explains:
"Most kernel applications utilizing the crypto API operate synchronously and on small buffer sizes, therefore do not benefit from QAT acceleration.
Reduce the priority of QAT implementations for both skcipher and aead algorithms, allowing more suitable alternatives to be selected by default."
The priority of these algorithms with the QAT driver are lowered from 4001 to just 100 to reduce the likelihood that the QAT accelerators get tasked with the work. Small buffer sizes not being worthwhile has been a common and known issue for Intel's accelerators found in recent Xeon processors.
Separately, the QAT driver in this crypto pull also drops ZUC 256 support for QAT Gen3 and current-generation Gen5 accelerators:
"crypto/qat: remove ZUC 256 support
Due to changes in the specification related to IV size and initialization sequence remove ZUC 256 support from Gen 3 and 5 hardware"
Meanwhile for the upcoming QAT Gen6 accelerators there is rate-limiting support added in Linux 6.17 along with telemetry support.
The crypto updates for Linux 6.17 also re-enable SHA384 usage in FIPS mode while disabling SHA1 code. The Zstd compression support within the Linux kernel has also been adapted to the asynchronous compression "acomp" interface rather than the synchronous compression "scomp" interface. In supporting the native asynchronous compression interface using Zstd streaming APIs, there is no longer the need for buffer linerization in the Zstd kernel usage.
See [3]this pull request for all of the Linux 6.17 crypto changes merged this week.
[1] https://www.phoronix.com/news/Intel-QAT-FSCRYPT-Linux-6.17
[2] https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/commit/?id=8024774190a5ef2af2c5846f60a50b23e0980a32
[3] https://lore.kernel.org/lkml/aIirh_7k4SWzE-bF@gondor.apana.org.au/
The Intel QAT crypto driver has lowered the priority for QAT usage with the SKCIPHER and AEAD algorithms for lack of benefit with the typical kernel use-cases. The [2]patch by Intel engineer Giovanni Cabiddu explains:
"Most kernel applications utilizing the crypto API operate synchronously and on small buffer sizes, therefore do not benefit from QAT acceleration.
Reduce the priority of QAT implementations for both skcipher and aead algorithms, allowing more suitable alternatives to be selected by default."
The priority of these algorithms with the QAT driver are lowered from 4001 to just 100 to reduce the likelihood that the QAT accelerators get tasked with the work. Small buffer sizes not being worthwhile has been a common and known issue for Intel's accelerators found in recent Xeon processors.
Separately, the QAT driver in this crypto pull also drops ZUC 256 support for QAT Gen3 and current-generation Gen5 accelerators:
"crypto/qat: remove ZUC 256 support
Due to changes in the specification related to IV size and initialization sequence remove ZUC 256 support from Gen 3 and 5 hardware"
Meanwhile for the upcoming QAT Gen6 accelerators there is rate-limiting support added in Linux 6.17 along with telemetry support.
The crypto updates for Linux 6.17 also re-enable SHA384 usage in FIPS mode while disabling SHA1 code. The Zstd compression support within the Linux kernel has also been adapted to the asynchronous compression "acomp" interface rather than the synchronous compression "scomp" interface. In supporting the native asynchronous compression interface using Zstd streaming APIs, there is no longer the need for buffer linerization in the Zstd kernel usage.
See [3]this pull request for all of the Linux 6.17 crypto changes merged this week.
[1] https://www.phoronix.com/news/Intel-QAT-FSCRYPT-Linux-6.17
[2] https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/commit/?id=8024774190a5ef2af2c5846f60a50b23e0980a32
[3] https://lore.kernel.org/lkml/aIirh_7k4SWzE-bF@gondor.apana.org.au/
phoronix