Skip to contentSkip to conversation

crypto: caam/qi2 - lower the algorithm priority

PATCH In review Vincent Jardin 3 participants 5 messages Sep 29 – Oct 8

Subsystems (2)
Crypto API Freescale CAAM (Cryptographic Acceleration and Assurance Module) driver
lore
Share & tools
lore

Vincent Jardin

author
#0 lore raw

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

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 <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Signed-off-by Vincent Jardin <[email protected]>

---
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(-)
drivers/crypto/caam/caamalg_qi2.c +1 -1
index 6b47bcc16a50..d3cb2bd5c41d 100644
@@ -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,

Signature · 1 line
Vincent Jardin <[email protected]>
#1 lore raw

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

Quoted 82 lines

-----Original Message-----
From: Vincent Jardin via B4 Relay <[email protected]>
Sent: 30 September 2026 01:59
To: Horia Geanta <[email protected]>; Pankaj Gupta <[email protected]>; Sahil Malhotra <[email protected]>; Herbert Xu <[email protected]>; David S. Miller <[email protected]>; Gaurav Jain <[email protected]>
Cc: Eric Biggers <[email protected]>; [email protected]; linux- [email protected]; Vincent Jardin <[email protected]>
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 <[email protected]>

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 <[email protected]>

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 <[email protected]>

---
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(-)
drivers/crypto/caam/caamalg_qi2.c +1 -1
index 6b47bcc16a50..d3cb2bd5c41d 100644
@@ -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 <[email protected]>

author
#2 lore raw

Hi Sahil,

Quoted 5 lines · 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.

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.

Quoted 3 lines

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

Reviewed-by Sahil Malhotra
#3 lore raw

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 <[email protected]>

Regards,
Sahil Malhotra

NXP Confidential

Quoted 70 lines

-----Original Message-----
From: Vincent Jardin <[email protected]>
Sent: 30 September 2026 14:39
To: Sahil Malhotra (OSS) <[email protected]>
Cc: Horia Geanta <[email protected]>; Pankaj Gupta <[email protected]>; Herbert Xu <[email protected]>; David S. Miller <[email protected]>; Gaurav Jain <[email protected]>; Eric Biggers <[email protected]>; [email protected]; linux- [email protected]
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,

Quoted 4 lines · 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?

Quoted 1 line

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.

Quoted 3 lines

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

maintainer
#4 lore raw
In reply to Vincent Jardin
Quoted 22 lines · On Tue, Sep 29, 2026 at 10:29:04PM +0200, Vincent Jardin via B4 Relay wrote:

From: Vincent Jardin <[email protected]>

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 <[email protected]>
Link https://lore.kernel.org/r/[email protected] open here
Signed-off-by Vincent Jardin <[email protected]>

---
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

Quoted 3 lines
---
 drivers/crypto/caam/caamalg_qi2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Patch applied. Thanks.

Signature · 3 lines
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt