[PATCH v4 1/2] eal: support dmabuf

[Cliff Burdick]

>  [-----Original Message-----
>  From: Burakov, Anatoly <anatoly.burakov at intel.com>
>  Sent: Thursday, February 12, 2026 5:58 AM
>  To: Cliff Burdick <cburdick at nvidia.com>; dev at dpdk.org
>  Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) <thomas at monjalon.net>
>  Subject: Re: [PATCH v4 1/2] eal: support dmabuf]()
>   
>  External email: Use caution opening links or attachments
>   
>   
>  On 2/4/2026 4:50 PM, Cliff Burdick wrote:
>  > dmabuf is a modern Linux kernel feature to allow DMA transfers between
>  > two drivers. Common examples of usage are streaming video devices and
>  > NIC to GPU transfers. Prior to dmabuf users had to load proprietary
>  > drivers to expose the DMA mappings. With dmabuf the proprietary
>  > drivers are no longer required.
>  > 
>  > A new api function rte_extmem_register_dmabuf is introduced to create
>  > the mapping from a dmabuf file descriptor. dmabuf uses a file
>  > descriptor and an offset that has been pre-opened with the kernel. The
>  > kernel uses the file descriptor to map to a VA pointer. To avoid ABI
>  > changes, a static struct is used inside of eal_common_memory.c, and
>  > lookups are done on this struct rather than from the rte_memseg_list.
>  > 
>  > Ideally we would like to add both the dmabuf file descriptor and
>  > offset to rte_memseg_list, but it's not clear if we can reuse existing
>  > fields when using the dmabuf API.
>  > 
>  > We could rename the external flag to a more generic "properties" flag
>  > where "external" is the lowest bit, then we can use the second bit to
>  > indicate the presence of dmabuf. In the presence of the flag for
>  > dmabuf we could reuse the base_va address field for the dmabuf offset,
>  > and the socket_id for the file descriptor.
>  > 
>  > Signed-off-by: Cliff Burdick <[cburdick at nvidia.com](mailto:cburdick at nvidia.com)>
>  > ---
>   
>  Hi,
>   
>  A few random thoughts about the patchset.
>   
>  For one, this API is obviously Linux-only. This in itself is not a problem (we do have VFIO API...) but I would really like to avoid that if possible.
>   
>  For another, I don't see any support for secondary processes - the dmabuf array is process-local, and calling register() from secondary process would presumably either fail or create a duplicate segment, depending on exactly what you pass into the register call. If this scenario isn't supported, it should at least be explicitly disallowed and documented to be such.
>   
>  My biggest concern is that this is creating another type of external memory segment and thus segregating the API, but isn't doing it in a way that is generic. I can see a valid usecase for this, but what we're essentially doing here is storing some metadata together with the segment. So, perhaps, this is what we should do? That would seem like a cleanest solution for me, and it would extend usefulness of the API to other use cases where there may be a requirement to store some metadata/fd/whatever with the segment.
>   
>  You could then build another API on top of this (a library?) that would handle things like secondary process synchronization with IPC, so that you have all fd's valid in all processes.
>   
>  Thoughts?
>  --
>  Thanks,
>  Anatoly

Hi Anatoly, sorry for the delay. It is true that it's Linux-only. I did not see either BSD or Windows having an equivalent to dmabuf, but I'm not very familiar with them. 

Adding support for secondary processes is something I'd rather delay for a later release if possible since it could be a lot more work. I can add a guard that says it's not supported if a secondary process calls the register function.

For a more generic API are you suggesting something like rte_extmem_register_ex() that would take an enum type along with some opaque metadata, of which DMABUF is one type?