[PATCH v2] crypto: caam/qi2 - lower the algorithm priority

[PATCH v2] crypto: caam/qi2 - lower the algorithm priority

[Vincent Jardin via B4 Relay]

From: Vincent Jardin <vjardin@free.fr>

Lower the priority to 100, as done for QAT in commit
  8024774190a5 ("crypto: qat - lower priority for skcipher and aead algorithms").

The SEC stays reachable by driver name, and user space can raise its
priority through the crypto_user interface.

Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
Link: https://lore.kernel.org/r/aruvJECCDNdguMdw@gondor.apana.org.au
Signed-off-by: Vincent Jardin <vjardin@free.fr>
---
v2 lowers the priority to 100, as was done for QAT, and leaves the
choice to user space through crypto_user.
---
Changes in v2:
- Drop both the dpaa2_caam.priority module parameter and the
  fsl,qi2-crypto-priority DT property
- Lower the default priority to 100, user space adjust it with
  crypto_user (Herbert).
- No policy in the device tree (Krzysztof, Eric).
- Link to v1: https://lore.kernel.org/r/20260928-for-upstream-caam-qi2-priority-v1-0-e4a8e5f01dbc@free.fr
---
 drivers/crypto/caam/caamalg_qi2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/caam/caamalg_qi2.c b/drivers/crypto/caam/caamalg_qi2.c
index 6b47bcc16a50..d3cb2bd5c41d 100644
--- a/drivers/crypto/caam/caamalg_qi2.c
+++ b/drivers/crypto/caam/caamalg_qi2.c
@@ -26,7 +26,7 @@
 #include <crypto/xts.h>
 #include <linux/unaligned.h>
 
-#define CAAM_CRA_PRIORITY	2000
+#define CAAM_CRA_PRIORITY	100
 
 /* max key is sum of AES_MAX_KEY_SIZE, max split key size */
 #define CAAM_MAX_KEY_SIZE	(AES_MAX_KEY_SIZE + CTR_RFC3686_NONCE_SIZE + \

---
base-commit: 67aefeccc4101a93627f36abbd049f191b54f903
change-id: 20260928-for-upstream-caam-qi2-priority-76301b8eb3a6

Best regards,
-- 
Vincent Jardin <vjardin@free.fr>

RE: [EXT] [PATCH v2] crypto: caam/qi2 - lower the algorithm priority

[Sahil Malhotra (OSS)]

Hi Vincent,

I'm not sure I understand the need for this change.
Is it now expected that hardware accelerators should have a lower default priority than ARM CE?
Users who want to use ARM CE can already choose it at runtime, so changing the default priority does not seem necessary from my perspective.

Regards,
 Sahil Malhotra


NXP Confidential
> -----Original Message-----
> From: Vincent Jardin via B4 Relay <devnull+vjardin.free.fr@kernel.org>
> Sent: 30 September 2026 01:59
> To: Horia Geanta <horia.geanta@nxp.com>; Pankaj Gupta
> <pankaj.gupta@nxp.com>; Sahil Malhotra <sahil.malhotra@nxp.com>; Herbert
> Xu <herbert@gondor.apana.org.au>; David S. Miller <davem@davemloft.net>;
> Gaurav Jain <gaurav.jain@nxp.com>
> Cc: Eric Biggers <ebiggers@kernel.org>; linux-crypto@vger.kernel.org; linux-
> kernel@vger.kernel.org; Vincent Jardin <vjardin@free.fr>
> Subject: [EXT] [PATCH v2] crypto: caam/qi2 - lower the algorithm priority
>
> Caution: This is an external email. Please take care when clicking links or opening
> attachments. When in doubt, report the message using the 'Report this email'
> button
>
>
> From: Vincent Jardin <vjardin@free.fr>
>
> Lower the priority to 100, as done for QAT in commit
>   8024774190a5 ("crypto: qat - lower priority for skcipher and aead algorithms").
>
> The SEC stays reachable by driver name, and user space can raise its priority
> through the crypto_user interface.
>
> Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
> Link:
> https://lore.kernel/
> .org%2Fr%2FaruvJECCDNdguMdw%40gondor.apana.org.au&data=05%7C02%7Cs
> ahil.malhotra%40nxp.com%7C10c43f21b2134717d1f108df1e6852ed%7C686ea1
> d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C639263105554431204%7CUnkno
> wn%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAi
> OiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3
> wozUHYpxdImjIBVE%2FwfWRA0St1JtJlSYfx3hgZAhOw%3D&reserved=0
> Signed-off-by: Vincent Jardin <vjardin@free.fr>
> ---
> v2 lowers the priority to 100, as was done for QAT, and leaves the choice to user
> space through crypto_user.
> ---
> Changes in v2:
> - Drop both the dpaa2_caam.priority module parameter and the
>   fsl,qi2-crypto-priority DT property
> - Lower the default priority to 100, user space adjust it with
>   crypto_user (Herbert).
> - No policy in the device tree (Krzysztof, Eric).
> - Link to v1:
> https://lore.kernel/
> .org%2Fr%2F20260928-for-upstream-caam-qi2-priority-v1-0-
> e4a8e5f01dbc%40free.fr&data=05%7C02%7Csahil.malhotra%40nxp.com%7C10c
> 43f21b2134717d1f108df1e6852ed%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> C0%7C0%7C639263105554463258%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0e
> U1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIld
> UIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XNOC7W92lH0NlKVcUyK69O5VrYCl4
> 9F4wwr3dU1Q6Mo%3D&reserved=0
> ---
>  drivers/crypto/caam/caamalg_qi2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/caam/caamalg_qi2.c
> b/drivers/crypto/caam/caamalg_qi2.c
> index 6b47bcc16a50..d3cb2bd5c41d 100644
> --- a/drivers/crypto/caam/caamalg_qi2.c
> +++ b/drivers/crypto/caam/caamalg_qi2.c
> @@ -26,7 +26,7 @@
>  #include <crypto/xts.h>
>  #include <linux/unaligned.h>
>
> -#define CAAM_CRA_PRIORITY      2000
> +#define CAAM_CRA_PRIORITY      100
>
>  /* max key is sum of AES_MAX_KEY_SIZE, max split key size */
>  #define CAAM_MAX_KEY_SIZE      (AES_MAX_KEY_SIZE +
> CTR_RFC3686_NONCE_SIZE + \
>
> ---
> base-commit: 67aefeccc4101a93627f36abbd049f191b54f903
> change-id: 20260928-for-upstream-caam-qi2-priority-76301b8eb3a6
>
> Best regards,
> --
> Vincent Jardin <vjardin@free.fr>
>
>

Re: [EXT] [PATCH v2] crypto: caam/qi2 - lower the algorithm priority

[Vincent Jardin]

Hi Sahil,

Le 30/09/26 07:21, Sahil Malhotra (OSS) a écrit :
> Hi Vincent,
> 
> I'm not sure I understand the need for this change.
> Is it now expected that hardware accelerators should have a lower default priority than ARM CE?
> Users who want to use ARM CE can already choose it at runtime, so changing the default priority does not seem necessary from my perspective.

Not as a general rule. The default priority should select what is best
for most users with the platform as it ships, and on the LX2160A this
is the CE.

Measured on an LX2160A (16x Cortex-A72 at 2.2 GHz) with tcrypt,
AES-128-GCM encryption, 4 KiB requests:

    gcm-aes-ce                      1 core      1107 MB/s
    gcm-aes-caam-qi2, 1 in flight               128 MB/s
    gcm-aes-caam-qi2, 32 in flight  1.4 cores   418 MB/s

It is the same for cbc, ctr, xts, rfc4106 and sha256/512, at every
size I measured: the SEC is slower, and its driver path costs more CPU
per byte than doing the crypto on the core.

The SEC can win, but only in a narrow case. The MC DPC and DPL have to
be tuned for it (one DPIO and one DPSECI queue pair per CPU, and the
SEC coherency setting in the DPC), and the load has to be large
buffers over many keys. I did set such scenario for my internal
working cases, but it they are not the default cases.

This is the case of QAT in commit
  8024774190a5 ("crypto: qat - lower priority for skcipher and aead algorithms")
most users call the crypto API synchronously on small buffers and do not
benefit from the accelerator.

  > Users who want to use ARM CE can already choose it at runtime, so
  > changing the default priority does not seem necessary from my
  > perspective.

In practice it works the other way round. IPsec, dm-crypt or kTLS ask
for an algorithm by name and get the highest priority, they do not
choose a driver. The users who gain from the SEC are the ones who also
tune the DPC and DPL for it, and they can raise its priority with
crypto_user, or ask for the driver by name.

So the CPU should be the 1st gear, and the SEC should be the next one,
for those who set the platform up for it. It is not a statement that hardware
crypto is slower in general.

I only measured the LX2160A, not the LS1088A or LS2088A. If you have
numbers there with the SEC ahead, I'm happy to look at them.

Best regards,
  Vincent

RE: [EXT] [PATCH v2] crypto: caam/qi2 - lower the algorithm priority

[Sahil Malhotra (OSS)]

Hi Vincent,

Got your point, Regarding the numbers on LS1088 and LS2088 I need to fetch them.
For this patch, I am ok.

Reviewed-by: Sahil Malhotra <sahil.malhotra@nxp.com>

Regards,
Sahil Malhotra


NXP Confidential
> -----Original Message-----
> From: Vincent Jardin <vjardin@free.fr>
> Sent: 30 September 2026 14:39
> To: Sahil Malhotra (OSS) <sahil.malhotra@oss.nxp.com>
> Cc: Horia Geanta <horia.geanta@nxp.com>; Pankaj Gupta
> <pankaj.gupta@nxp.com>; Herbert Xu <herbert@gondor.apana.org.au>; David S.
> Miller <davem@davemloft.net>; Gaurav Jain <gaurav.jain@nxp.com>; Eric
> Biggers <ebiggers@kernel.org>; linux-crypto@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: Re: [EXT] [PATCH v2] crypto: caam/qi2 - lower the algorithm priority
>
> Caution: This is an external email. Please take care when clicking links or opening
> attachments. When in doubt, report the message using the 'Report this email'
> button
>
>
> Hi Sahil,
>
> Le 30/09/26 07:21, Sahil Malhotra (OSS) a écrit :
> > Hi Vincent,
> >
> > I'm not sure I understand the need for this change.
> > Is it now expected that hardware accelerators should have a lower default
> priority than ARM CE?
> > Users who want to use ARM CE can already choose it at runtime, so changing
> the default priority does not seem necessary from my perspective.
>
> Not as a general rule. The default priority should select what is best for most
> users with the platform as it ships, and on the LX2160A this is the CE.
>
> Measured on an LX2160A (16x Cortex-A72 at 2.2 GHz) with tcrypt, AES-128-GCM
> encryption, 4 KiB requests:
>
>     gcm-aes-ce                      1 core      1107 MB/s
>     gcm-aes-caam-qi2, 1 in flight               128 MB/s
>     gcm-aes-caam-qi2, 32 in flight  1.4 cores   418 MB/s
>
> It is the same for cbc, ctr, xts, rfc4106 and sha256/512, at every size I measured:
> the SEC is slower, and its driver path costs more CPU per byte than doing the
> crypto on the core.
>
> The SEC can win, but only in a narrow case. The MC DPC and DPL have to be
> tuned for it (one DPIO and one DPSECI queue pair per CPU, and the SEC
> coherency setting in the DPC), and the load has to be large buffers over many
> keys. I did set such scenario for my internal working cases, but it they are not the
> default cases.
>
> This is the case of QAT in commit
>   8024774190a5 ("crypto: qat - lower priority for skcipher and aead algorithms")
> most users call the crypto API synchronously on small buffers and do not benefit
> from the accelerator.
>
>   > Users who want to use ARM CE can already choose it at runtime, so
>   > changing the default priority does not seem necessary from my
>   > perspective.
>
> In practice it works the other way round. IPsec, dm-crypt or kTLS ask for an
> algorithm by name and get the highest priority, they do not choose a driver. The
> users who gain from the SEC are the ones who also tune the DPC and DPL for it,
> and they can raise its priority with crypto_user, or ask for the driver by name.
>
> So the CPU should be the 1st gear, and the SEC should be the next one, for those
> who set the platform up for it. It is not a statement that hardware crypto is slower
> in general.
>
> I only measured the LX2160A, not the LS1088A or LS2088A. If you have numbers
> there with the SEC ahead, I'm happy to look at them.
>
> Best regards,
>   Vincent

Re: [PATCH v2] crypto: caam/qi2 - lower the algorithm priority

[Herbert Xu]

On Tue, Sep 29, 2026 at 10:29:04PM +0200, Vincent Jardin via B4 Relay wrote:
> From: Vincent Jardin <vjardin@free.fr>
> 
> Lower the priority to 100, as done for QAT in commit
>   8024774190a5 ("crypto: qat - lower priority for skcipher and aead algorithms").
> 
> The SEC stays reachable by driver name, and user space can raise its
> priority through the crypto_user interface.
> 
> Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
> Link: https://lore.kernel.org/r/aruvJECCDNdguMdw@gondor.apana.org.au
> Signed-off-by: Vincent Jardin <vjardin@free.fr>
> ---
> v2 lowers the priority to 100, as was done for QAT, and leaves the
> choice to user space through crypto_user.
> ---
> Changes in v2:
> - Drop both the dpaa2_caam.priority module parameter and the
>   fsl,qi2-crypto-priority DT property
> - Lower the default priority to 100, user space adjust it with
>   crypto_user (Herbert).
> - No policy in the device tree (Krzysztof, Eric).
> - Link to v1: https://lore.kernel.org/r/20260928-for-upstream-caam-qi2-priority-v1-0-e4a8e5f01dbc@free.fr
> ---
>  drivers/crypto/caam/caamalg_qi2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt