Hello, It's a pity this patch didn't move. How can we make the design discussion progressing?
23/04/2026 19:06, Cliff Burdick: > From: Burakov, Anatoly <[email protected]> > > 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?
