Re: [PATCH 0/3] crypto: caam/qi2 - algorithm priority configurable

[Vincent Jardin]

Hi Eric,

On Mon, Sep 28, 2026 at 10:41:43PM +0000, Eric Biggers wrote:
> Is there *any* real-world use case in which these caamalg_qi2.c
> algorithms are worth using?  This looks like another one of those
> problematic drivers pushed by the hardware vendor as a checkbox feature.
> Just doing the crypto on the CPU is almost always much faster and more
> reliable.

It is not black and white, and I am working on some optimizations.
Today, with one key, one A72 core with the Crypto Extensions is about
2x better than the SEC, at every buffer size. However, that core is
then at its limit: 6 to 9 Gbps of AES-128-GCM, fully busy.

With many keys and many buffers in flight, it changes. With 16 KiB
buffers, 16 keys and some WIP fixes (MC firmware configuration mosty, maybe
few kernel fixes), one A72 core feeding the SEC reaches 47.1 Gbps, while
the same core does 9.3 Gbps with the Crypto Extensions. At 4 KiB it is
14.4 against 8.5 Gbps. At low network packet size (WIP about 1400 octet) the
A72 wins.

For single flows, the SEC should not be used: with the current kernel code,
one key cannot go past about 4 Gbps.

So, even if it is tempting to drop caamalg_qi2.c, I believe some users
still have a use for it. Note: I only focused on AES-128-GCM.

> As shown by your other patch
> (https://lore.kernel.org/linux-crypto/20260928-for-upstream-caam-qi-plain-keylen-v1-1-6edb56649cf9@xxxxxxx/)
> it also seems that this driver has been critically broken for the last
> year, with it being unable to set keys.  Evidently, no one has tested or
> used it in the last year until now.

Agreed. CONFIG_CRYPTO_SELFTESTS caught it on the first boot.

> It also has the usual anti-patterns like supporting MD5 and DES.

I cannot argue with that, but I would rather not be the one who drops
them from caamalg_qi2.c.

> I really don't see the point.  Why do people put themselves through
> these issues at all?  It seems this functionality should just be
> disabled everywhere, without putting policy in the device tree which as
> has been noted many times isn't the right place for it.

Definitely, the device tree is not the right place, I get the point.
v2 will move away from it.

My first goal is to get these features working again on the
LX2160A, and to be able to select the crypto backend.

Best regards,
  Vincent