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 <[email protected]>
---
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
