Secondary failed allocate mbuff from DPDK Pool

Chidananda22 — Thu, 27 Aug 2026 11:06:02 GMT

hi All,

Using : LX2160 LSDK 2108 main
MC firmware version: 10.32.0

DPDK Version : dpdk_19_11_tags_LSDK20.04-isc-09

Primary ( DPDK ) Process : Create a mbuff Pool using [ rte_pktmbuf_pool_create("dlmempool", ]

Secondary ( DPDK ) Process : fails to allocate mbuff using API [ rte_pktmbuf_alloc(mempool) ]

In Secondary i can see mempool is correct. I can see mbuff available is full. The failure happens for 1st mbuff allocation using rte_pktmbuf_alloc.

Any solution for this. Thanks.

Re: Secondary failed allocate mbuff from DPDK Pool

Bio_TICFSL — Thu, 27 Aug 2026 16:26:24 GMT

Hello,

The secondary process must map hugepages at the same virtual address as the primary. If ASLR is active, the secondary will resolve the mempool pointer to a different virtual address, causing the first allocation to fail.

echo 0 > /proc/sys/kernel/randomize_va_space

Run this before launching either the primary or secondary process.

2. Provision Sufficient DPMCP Objects

Create as many DPMCP objects as the total number of processes (primary + secondary). For 1 primary + 1 secondary, you need at least 2 DMPCPs:

export DPMCP_COUNT=3   # for 1 Primary + 2 Secondary (always provision +1 as buffer)
./dynamic_dpl.sh dpmac.X

3. Provision Sufficient DPIO Objects

Each process needs its own DPIO portals. The formula is:

(Total Processes) × (cores per process + 1 extra per process)

For example, 1 primary (2 cores) + 1 secondary (2 cores) = at minimum 9 DPIOs.

export DPIO_COUNT=20   # set generously

4. Correctly Blacklist/Whitelist Devices in the Secondary

The secondary process must NOT re-initialize I/O devices (dpni, dpbp, dpcon, dpseci). Only dpio and dpmcp should be initialized by the secondary. Pass the correct blacklist flags:

# Secondary process example — blacklist all dpni/dpbp/dpcon, allow only dpio + dpmcp
./your_secondary_app --proc-type=secondary \
  -b fslmc:dpni.X \
  -b fslmc:dpbp.X \
  -b fslmc:dpcon.X \
  -- [app args]

Or alternatively, explicitly whitelist only the dpio and dpmcp objects assigned to the secondary:

./your_secondary_app --proc-type=secondary \
  -w fslmc:dpio.Y \
  -w fslmc:dpmcp.Z \
  -- [app args]

5. Use `--proc-type=secondary` EAL Argument

Ensure the secondary is launched with the correct EAL flag:

./your_secondary_app -c <coremask> -n 1 --proc-type=secondary ...

Or use --proc-type=auto to let DPDK auto-detect.

6. Verify the Mempool Lookup in Secondary

In the secondary, do not call rte_pktmbuf_pool_create again. Instead, look up the existing pool created by the primary:

// In secondary process:
struct rte_mempool *mempool = rte_mempool_lookup("dlmempool");
if (mempool == NULL) {
    // Error: pool not found — ASLR or hugepage mapping issue
}
struct rte_mbuf *m = rte_pktmbuf_alloc(mempool);

If rte_mempool_lookup returns a valid non-NULL pointer but rte_pktmbuf_alloc still returns NULL, the issue is almost certainly the DPIO portal not being initialized for the secondary's thread/core.

Regards

Re: Secondary failed allocate mbuff from DPDK Pool

Chidananda22 — Thu, 27 Aug 2026 17:23:16 GMT

thanks i will try these options and update you by tomorrow

topic Re: Secondary failed allocate mbuff from DPDK Pool in Layerscape

Secondary failed allocate mbuff from DPDK Pool

Re: Secondary failed allocate mbuff from DPDK Pool

3. Provision Sufficient DPIO Objects

4. Correctly Blacklist/Whitelist Devices in the Secondary

5. Use --proc-type=secondary EAL Argument

6. Verify the Mempool Lookup in Secondary

Re: Secondary failed allocate mbuff from DPDK Pool

5. Use `--proc-type=secondary` EAL Argument