On Tue, 24 May 2022 08:51:31 +0100 Giovanni Cabiddu <giovanni.cabiddu@xxxxxxxxx> wrote: Hi, > On Wed, May 18, 2022 at 02:00:40PM +0100, Yoan Picchi wrote: > > >> From: Yoan Picchi <yoan.picchi@xxxxxxx> > > >> > > >> The QAT acceleration card can be very helpfull for some tasks like > > >> dealing with IPSEC but it is currently restricted to be used only on x86 > > machine. > > >> Looking at the code we didn't see any reasons why those drivers might > > >> not work on other architectures. We've successfully built all of them > > >> on x86, arm64, arm32, mips64, powerpc64, riscv64 and sparc64. > > >> > > >> We also have tested the driver with an Intel Corporation C62x Chipset > > >> QuickAssist Technology (rev 04) PCIe card on an arm64 server. After > > >> the numa patch, it works with the AF_ALG crypto userland interface, > > >> allowing us to encrypt some data with cbc for instance. We've also > > >> successfully created some VF, bound them to DPDK, and used the card > > >> this way, thus showing some real life usecases of x86 do work on arm64 > > too. > > >> > > >> Please let us know if we missed something that would warrants some > > >> further testing. > > >Thanks Yoan. > > > > > >Can you please confirm that you tested the driver on the platform you > > reported using a kernel with CONFIG_CRYPTO_MANAGER_DISABLE_TESTS not set and > > CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y and the self test >is passing? > > >You can check it by running > > >��� $ cat /proc/crypto | grep -B 4 passed | grep -e "qat_\|qat-" | sort > > This should report: > > >��� driver������ : qat_aes_cbc > > >��� driver������ : qat_aes_cbc_hmac_sha1 > > >��� driver������ : qat_aes_cbc_hmac_sha256 > > >��� driver������ : qat_aes_cbc_hmac_sha512 > > >��� driver������ : qat_aes_ctr > > >��� driver������ : qat_aes_xts > > >��� driver������ : qat-dh > > >��� driver������ : qat-rsa > > > > > >Note that if you are using the HEAD of cryptodev-2.6 you will have to > > either revert 8893d27ffcaf6ec6267038a177cb87bcde4dd3de or apply > > >https://patchwork.kernel.org/project/linux-crypto/list/?series=639755 as > > the algorithms have been temporarily disabled. > > > > > >Regards, > > > > > >-- > > >Giovanni > > > > Hi Giovanni. > > > > Thanks for the instructions, I did not know of this test. > > I rebuilt my kernel on arm64 with those parameter and I confirm I get the > > same output with > > $ cat /proc/crypto | grep -B 4 passed | grep -e "qat_\|qat-" | sort > Thats great. Thanks. > > Is the platform where you ran the tests little or big endian? It's definitely little endian. The cores in there can be switched between LE and BE, but I think realistically no one ever runs a BE configuration. Compiling the kernel for BE is rather straight-forward, but I wouldn't know of any serious userland to run with it (short of a self-compiled busybox or buildroot). > If little endian, can you re-test on a big endian system? So you can just compile a kernel with CONFIG_CPU_BIG_ENDIAN=y, but you cannot boot it easily, since CONFIG_EFI depends on !CPU_BIG_ENDIAN, and UEFI is the only way to boot that (server) machine. So kexec and a KVM guest are the other options. Kexec has the disadvantage of requiring a DT (because ACPI is also incompatible with BE), and for KVM we would need to check whether this actually works, since BE guests are much less tested, plus the device pass-through imposing more challenges. So testing this in BE is a bit more involved, and the practicality of such a setup is very questionable. If you are concerned, should we just say: depends on PCI && !CPU_BIG_ENDIAN At least until we have reports that confirm proper BE operation? Cheers, Andre
