lkml.org 
[lkml]   [2022]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH 2/2] Removes the x86 dependency on the QAT drivers
On Tue, 24 May 2022 08:51:31 +0100
Giovanni Cabiddu <giovanni.cabiddu@intel.com> wrote:

Hi,

> On Wed, May 18, 2022 at 02:00:40PM +0100, Yoan Picchi wrote:
> > >> From: Yoan Picchi <yoan.picchi@arm.com>
> > >>
> > >> 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

\
 
 \ /
  Last update: 2022-05-25 15:13    [W:0.090 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site