Hi Cliff and EAL Maintainers,
While testing the v4 patch series for a side-by-side CPU vs GPU low-latency
forwarding comparison using DPDK 26.03, we uncovered an unintended backward
compatibility break inside the legacy rte_extmem_register() wrapper path.
Currently, legacy applications calling the standard primitive fail
immediately
on the first page iteration with EINVAL. There are two distinct issues:
1. In rte_exmem_register, the legacy wrapper routes through
rte_extmem_register_dmabuf() passing a hardcoded -1 for the file
descriptor.
However, rte_extmem_register_dmabuf() enforces a strict guard check
right at
the entry gate:
if (dmabuf_fd < 0) { return -EINVAL; }
This rejects all legacy CPU host memory allocation calls. The legacy
wrapper
should instead bypass the experimental gate and map straight to the
underlying
static extmem_register() call.
2. In malloc_heap_create_external_seg,
Variable Shadowing/Corruption: Inside the page initialization tracking
loop,
the master list index iterator variable is clobbered by the sub-page
loop counter 'i'.
As a result:
eal_memseg_list_set_dmabuf_info(i, -1, 0);
targets a stale loop counter index instead of preserving the allocated
master memseg list.
This leaves the real segment list sitting at its zero-initialized
default (dmabuf_fd=0),
which poisons subsequent driver lookups (e.g. mlx5 trying to map
standard CPU frames
via reg_dmabuf_mr because fd=0 matches standard stdin instead of a clean
-1).
Fixing it requires caching 'i' into a persistent local tracker variable
(e.g., msl_idx)
immediately following the successful rte_fbarray_init() block, and
passing that
cached tracker to eal_memseg_list_set_dmabuf_info().
