Other NXP ProductsのトピックRe: Enable Hardware Crypto Engine

Enable Hardware Crypto Engine

namanverma — Thu, 20 Nov 2025 09:49:38 GMT

Hello sir,

Currently I am using NXP Layerscape 1046ARDB kit in which I am executing L2fwd-crypto code with the software crypto-device as INntel IPsec-mb. Also TLS is running parallely to it for key exchange

Now I want to migrate my code to kit with an objective to use Hardware crypto engine. So following are my queries related to it.

Q1) How can I enable the hardware crypto engine in the kit.

I'm currently giving command as:

meson setup build --crossfile config/arm/arm64 -dpaa-linux_gcc -Denabledrivers=bus/dpaa,mempool/dpaa,crypto/dpaa_sec

But only in Drivers section dma,raw,crypto dpaa is coming but not in enabled drivers section.

How to resolve it?

Q2) In the earlier version of the DPDK KNI was provided that is not available in newer version. So what is the alternative provided for this?

Re: Enable Hardware Crypto Engine

Bio_TICFSL — Thu, 20 Nov 2025 12:44:55 GMT

Hello,

Q1) To enable the hardware crypto engine:
The issue appears to be with your meson build command. For DPAA crypto acceleration support in DPDK, you need to properly include the DPAA Security driver. Check if you have the required dependencies installed and the correct Linux headers. The syntax in your command looks correct, but you may need to ensure your build environment has all necessary prerequisites.

Try adding the full path to the DPAA SEC driver in your command:
```
meson setup build --crossfile config/arm/arm64_dpaa_linux_gcc -Denable_drivers=bus/dpaa,mempool/dpaa,crypto/dpaa_sec
```

If you still don't see it in the enabled drivers section, verify the DPAA crypto accelerator is properly initialized in your kernel and that the required DPDK libraries are properly installed.

Q2) Regarding KNI (Kernel NIC Interface) alternatives:
In newer DPDK versions, KNI has been deprecated and removed. The recommended alternatives are:

1. AF_XDP (Address Family eXpress Data Path) - Provides a high-performance packet processing interface
2. AF_PACKET - A standard socket interface for packet processing
3. Virtio-user - For userspace networking applications

For your specific use case with TLS key exchange running in parallel with L2fwd-crypto, AF_XDP would likely provide the best performance characteristics as a KNI replacement.

Regards

Re: Enable Hardware Crypto Engine

namanverma — Sat, 22 Nov 2025 09:29:37 GMT

Hello,

I have enabled CAAM in my kernel module now. Now the problem I am encountering is :

Q1)

(Last lines of the output dmesg | grep -i caam )

Device caam-keygen registered

caam_jr 17300000.jr : failed to flush job ring 2.

probe of 17300000.jr failed with error -5.

Q2)

for af-xdp the traffic coming on port eno1 is handled like this

sudo ethtool -L eno1 combined 2

# Add a flow rule to direct TCP traffic destined for port 443 to RX queue 1
sudo ethtool -N eno1 flow-type tcp4 dst-port 443 action 1

./dpdk_app ... --vdev="net_af_xdp0,iface=eno1,start_queue=1,queue_count=1" ...

nb_rx = rte_eth_rx_burst(portid, 0, pkts_burst, MAX_PKT_BURST);

Here I am giving that specific portid on which data is coming.

Please calrify the queries.

Re: Enable Hardware Crypto Engine

Bio_TICFSL — Mon, 24 Nov 2025 14:01:37 GMT

Hello,

1) CAAM utilizes multiple "job rings" to manage and process cryptographic requests. Each job ring acts as a queue where the operating system can submit cryptographic jobs for the CAAM hardware to execute.

"failed to flush job ring 2":
This error suggests that the system attempted to clear or finalize outstanding jobs on Job Ring 2, but the operation failed. This can happen for various reasons, including:

Errors in the CAAM driver or other kernel components that manage the job rings. This could involve incorrect handling of scatter-gather lists, memory access issues, or timing problems.

In some cases, mismatches between the U-Boot version (which initializes the CAAM) and the Linux kernel version can lead to such errors.

Another part of the system might be interfering with the operation of Job Ring 2.

Potential Solutions and Troubleshooting:

Update U-Boot and Kernel:

Ensure that both your U-Boot and Linux kernel versions are compatible and up-to-date, especially if you are using NXP's Software Development Kit (SDK).
Check for Patches:

Search for known bugs and patches related to CAAM and job ring flushing on the NXP community forums or relevant mailing lists.
Disable or Configure CAAM:

If the error is persistent and you don't critically rely on CAAM acceleration for that specific job ring, you might consider disabling it in the device tree or kernel configuration as a temporary workaround or for testing.
Examine Kernel Logs:

Look for other related error messages or warnings in the kernel logs (dmesg) that might provide more context about the failure.
Review Device Tree Configuration:

Verify that the CAAM and its job rings are correctly configured in your device tree.

#
2Here is a breakdown of the command and its prerequisites:

Command Breakdown

--vdev="net_af_xdp0,...": Instructs the DPDK EAL (Environment Abstraction Layer) to create a virtual device using the net_af_xdp driver. The name net_af_xdp0 is a unique identifier for this specific device instance within the DPDK application.

iface=eno1: Specifies the name of the host kernel network interface (eno1) that the AF_XDP socket will attach to (this is a required option).

start_queue=1: Specifies that the AF_XDP socket should bind to Rx/Tx queue number 1 of the eno1 interface (queues are typically 0-indexed).

queue_count=1: Specifies that this PMD instance will manage a single queue, starting from start_queue (i.e., only queue 1).

Prerequisites and Setup

To use this configuration successfully, the following prerequisites must be met on the Linux host system:

#
Kernel Support: The Linux kernel must be version 4.18 or later and compiled with CONFIG_XDP_SOCKETS=y enabled.
- Libraries: The libxdp (version >= 1.2.2) and libbpf libraries must be installed.
- Interface Configuration: The target network interface (eno1) must be configured in the kernel:
  
  Multiple Queues: The interface's driver must support multiple queues, and the total number of configured queues must be at least start_queue + queue_count (i.e., at least 2 queues in this case: queue 0 and queue 1).
  
  You can set the number of queues using ethtool, for example:
  
  bash
- sudo ethtool -L eno1 combined 2
  
  This ensures that traffic can be directed to queue 1, which the DPDK application is listening on.
- XDP Program: The AF_XDP PMD typically loads a default XDP program onto the interface to redirect packets to the user-space memory buffer.
- Permissions: The application must have sufficient permissions (e.g., run as root or with appropriate capabilities) to access the network interfaces and use AF_XDP sockets.
The command is a valid way to isolate traffic processing to a specific non-default queue using the AF_XDP driver in a DPDK application

Regards