[PATCH v4 1/2] eal: support dmabuf

[Anders Franzen]

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().
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/dev/attachments/20260703/61e5c97c/attachment.htm>