2408883_en-US

[#1]

Secondary failed allocate mbuff from DPDK Pool

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 Poolthanks i will try these options and update you by tomorrowRe: Secondary failed allocate mbuff from DPDK Pool

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