Hi Zhu Yanjun, Thank you for reaching out and revisiting my 2021 proposal.
Regarding the current status, I haven't been able to make much progress recently as other tasks have taken higher priority. However, I still believe this integration is important. >From a technical perspective, as pointed out during the previous reviews, there were indeed issues with how dma_buf_map was being used. To address this in today's context, I believe we should transition to using iosys_map. I am still interested in this direction. While my current bandwidth is limited, I would welcome any collaboration—especially regarding the implementation of iosys_map support within rxe or the RDMA core. I'd be happy to discuss the technical details of this transition if you'd like to dive deeper. Best, Shunsuke Mie 2026年2月19日(木) 13:43 Zhu Yanjun <[email protected]>: > 在 2021/11/22 3:08, Shunsuke Mie 写道: > > This patch series add a dma-buf support for rxe driver. > > > > A dma-buf based memory registering has beed introduced to use the memory > > region that lack of associated page structures (e.g. device memory and > CMA > > managed memory) [1]. However, to use the dma-buf based memory, each rdma > > device drivers require add some implementation. The rxe driver has not > > support yet. > > > > [1] https://www.spinics.net/lists/linux-rdma/msg98592.html > > > > To enable to use the dma-buf memory in rxe rdma device, add some changes > > and implementation in this patch series. > > > > This series consists of two patches. The first patch changes the IB core > > to support for rdma drivers that has not dma device. The secound patch > adds > > the dma-buf support to rxe driver. > > > Hi, Shunsuke Mie > > I was revisiting your 2021 proposal around dma-buf integration with RDMA > and the related discussions at the time. > > As you know, dma-buf usage in RDMA-related workflows has gained more > traction recently, and we are seeing increasing interest in > heterogeneous memory and cross-device buffer sharing. Given the changes > in the ecosystem since then, I’m wondering whether you think the > original direction might be worth reconsidering. > > Do you have any interest in continuing that line of work, or updating > the design based on today’s context? If not, I’d still appreciate your > perspective on what you see as the main blockers from the previous > discussions, and whether you think the landscape has changed enough to > justify another attempt. > > Depending on the direction, we may consider exploring dma-buf support in > rxe or at the core level, but I’d prefer to first understand your view > before moving forward. > > Zhu Yanjun > > > Related user space RDMA library changes are provided as a separate patch. > > > > v4: > > * Fix warnings, unused variable and casting > > v3: https://www.spinics.net/lists/linux-rdma/msg106776.html > > * Rebase to the latest linux-rdma 'for-next' branch (5.15.0-rc6+) > > * Fix to use dma-buf-map helpers > > v2: https://www.spinics.net/lists/linux-rdma/msg105928.html > > * Rebase to the latest linux-rdma 'for-next' branch (5.15.0-rc1+) > > * Instead of using a dummy dma_device to attach dma-buf, just store > > dma-buf to use software RDMA driver > > * Use dma-buf vmap() interface > > * Check to pass tests of rdma-core > > v1: https://www.spinics.net/lists/linux-rdma/msg105376.html > > * The initial patch set > > * Use ib_device as dma_device. > > * Use dma-buf dynamic attach interface > > * Add dma-buf support to rxe device > > > > Shunsuke Mie (2): > > RDMA/umem: Change for rdma devices has not dma device > > RDMA/rxe: Add dma-buf support > > > > drivers/infiniband/core/umem_dmabuf.c | 20 ++++- > > drivers/infiniband/sw/rxe/rxe_loc.h | 2 + > > drivers/infiniband/sw/rxe/rxe_mr.c | 113 ++++++++++++++++++++++++++ > > drivers/infiniband/sw/rxe/rxe_verbs.c | 34 ++++++++ > > include/rdma/ib_umem.h | 1 + > > 5 files changed, 166 insertions(+), 4 deletions(-) > > > >
