> [-----Original Message----- > From: Burakov, Anatoly <[email protected]> > Sent: Thursday, February 12, 2026 5:58 AM > To: Cliff Burdick <[email protected]>; [email protected] > Cc: NBU-Contact-Thomas Monjalon (EXTERNAL) <[email protected]> > 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 > <[[email protected]](mailto:[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
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?
