On Thu, Jun 12, 2025 at 09:50:26AM +0100, Giovanni Cabiddu wrote: > On Wed, Jun 11, 2025 at 11:25:21PM -0700, Eric Biggers wrote: > > ... > > > FWIW, here's what happens if you try to use the Intel QAT driver with > > dm-crypt: > > https://lore.kernel.org/r/cacsavz+mt3cfdxv0_yjh7d50trcgcrz12j3n6-hox2cz3+n...@mail.gmail.com/ > > /s/happens/happened/ > > ... and it got fixed > https://lore.kernel.org/all/20220506082327.21605-1-giovanni.cabi...@intel.com/
But it reached users in the first place, including stable kernels. And apparently the issues were going on for years and were known to the authors of the driver (https://lore.kernel.org/linux-crypto/91fe9f87-54d7-4140-4d1a-eac8e2081...@gmail.com/). We simply don't have issues like this with the AES-NI or VAES XTS code. And separately, QAT was reported to be much slower than AES-NI for synchronous use (https://lore.kernel.org/linux-crypto/0171515-7267-624-5a22-238af8296...@redhat.com/) Later, I added VAES accelerated AES-XTS code which is over twice as fast as AES-NI on the latest Intel CPUs, so that likely widened the gap even more. Yet, the QAT driver registers its "xts(aes)" implementation with priority 4001, compared to priority 800 for the VAES accelerated one. So the QAT one is the one that will be used by fscrypt! That seems like a major issue even just from a performance perspective. I expect this patch will significantly improve fscrypt performance on Intel servers that have QAT. - Eric _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
