Re: [PATCH rdma-next 00/15] RDMA: Introduce generic buffer descriptor infrastructure for umem

[Zhu Yanjun <yanjun.zhu@linux.dev>]

在 2026/3/29 4:26, Jiri Pirko 写道:
> Sat, Mar 28, 2026 at 12:03:47AM +0100, yanjun.zhu@linux.dev wrote:
>> On 3/25/26 8:00 AM, Jiri Pirko wrote:
>>> From: Jiri Pirko <jiri@nvidia.com>
>>>
>>> This patchset introduces a generic buffer descriptor infrastructure
>>> for passing memory buffers (dma-buf or user VA) to uverbs commands,
>>> and wires it up for CQ and QP creation in the uverbs core, efa, mlx5,
>>> bnxt_re and mlx4 drivers.
>> While the current patch set successfully introduces a generic buffer
>> descriptor
>>
>> infrastructure for CQ and QP creation, it raises the question of why
>>
>> Memory Region (MR) allocation and registration have not been integrated into
>>
>> this new ib_umem_list architecture.
>>
>> Given that MRs often require complex memory backing—such as discrete dma-buf
>> segments
>>
> >from GPUs or fragmented user-space virtual addresses—extending the
>> UVERBS_ATTR_BUFFERS
>>
>> array model to MRs would seem like a natural evolution. This would provide a
>> unified
>>
>> UAPI for handling heterogeneous memory sources and eliminate the need for
>> per-command
>>
>> attributes when registering composite memory regions. Are there specific
>> architectural
>>
>> constraints or synchronization concerns that necessitated keeping MR
>> registration on its legacy
>>
>> path for now?
>>
>> In short, I am wondering **whether this architecture can include MR (memory
>> region) or not**.
> I don't see why not. Seems like a straightforeward extension. Let's do
> that in a follow-up patchset, could we?

Thanks a lot. Appreciate it.

Zhu Yanjun

>
>
>> As such, CQ/QP/MR can use the same architecture.
>>
>> Zhu Yanjun
>>
>>> Instead of adding per-command UAPI attributes for each new buffer
>>> type, a single UVERBS_ATTR_BUFFERS array attribute carries all buffer
>>> descriptors. Each descriptor specifies a buffer type and is indexed by
>>> per-command slot enums. A consumption check ensures userspace and
>>> driver agree on which buffers are used.
>>> The patchset:
>>> 1. Introduces the core ib_umem_list infrastructure and UAPI.
>>> 2. Factors out CQ buffer umem processing into a helper.
>>> 3. Integrates umem_list into CQ creation, with fallback to existing
>>>      per-attribute path.
>>> 4-7. Converts efa, mlx5, bnxt_re and mlx4 to use umem_list for CQ
>>>      buffer.
>>> 8. Removes the legacy umem field from struct ib_cq, now that all
>>>      drivers use umem_list for CQ buffer management.
>>> 9. Adds a consumption check verifying all umem_list buffers were
>>>      consumed by the driver after CQ creation.
>>> 10. Integrates umem_list into QP creation.
>>> 11. Converts mlx5 QP creation to use umem_list.
>>> 12-15. Extends CQ and QP with doorbell record buffer slots and
>>>      converts mlx5 to use them.
>>>
>>> Note this re-works the original patchset trying to handle this:
>>> https://lore.kernel.org/all/20260203085003.71184-1-jiri@resnulli.us/
>>> The code is so much different I'm sending this is a new patchset.
>>>
>>> Jiri Pirko (15):
>>>     RDMA/core: Introduce generic buffer descriptor infrastructure for umem
>>>     RDMA/uverbs: Push out CQ buffer umem processing into a helper
>>>     RDMA/uverbs: Integrate umem_list into CQ creation
>>>     RDMA/efa: Use umem_list for user CQ buffer
>>>     RDMA/mlx5: Use umem_list for user CQ buffer
>>>     RDMA/bnxt_re: Use umem_list for user CQ buffer
>>>     RDMA/mlx4: Use umem_list for user CQ buffer
>>>     RDMA/uverbs: Remove legacy umem field from struct ib_cq
>>>     RDMA/uverbs: Verify all umem_list buffers are consumed after CQ
>>>       creation
>>>     RDMA/uverbs: Integrate umem_list into QP creation
>>>     RDMA/mlx5: Use umem_list for QP buffers in create_qp
>>>     RDMA/uverbs: Add doorbell record buffer slot to CQ umem_list
>>>     RDMA/mlx5: Use umem_list for CQ doorbell record
>>>     RDMA/uverbs: Add doorbell record buffer slot to QP umem_list
>>>     RDMA/mlx5: Use umem_list for QP doorbell record
>>>
>>>    drivers/infiniband/core/core_priv.h           |   1 +
>>>    drivers/infiniband/core/umem.c                | 248 ++++++++++++++++++
>>>    drivers/infiniband/core/uverbs_cmd.c          |  18 +-
>>>    drivers/infiniband/core/uverbs_std_types_cq.c | 158 ++++++-----
>>>    drivers/infiniband/core/uverbs_std_types_qp.c |  26 +-
>>>    drivers/infiniband/core/verbs.c               |  26 +-
>>>    drivers/infiniband/hw/bnxt_re/ib_verbs.c      |  23 +-
>>>    drivers/infiniband/hw/efa/efa_verbs.c         |  17 +-
>>>    drivers/infiniband/hw/mlx4/cq.c               |  21 +-
>>>    drivers/infiniband/hw/mlx5/cq.c               |  40 ++-
>>>    drivers/infiniband/hw/mlx5/doorbell.c         |  41 ++-
>>>    drivers/infiniband/hw/mlx5/mlx5_ib.h          |   3 +-
>>>    drivers/infiniband/hw/mlx5/qp.c               |  76 ++++--
>>>    drivers/infiniband/hw/mlx5/srq.c              |   2 +-
>>>    include/rdma/ib_umem.h                        |  54 ++++
>>>    include/rdma/ib_verbs.h                       |   5 +-
>>>    include/rdma/uverbs_ioctl.h                   |  14 +
>>>    include/uapi/rdma/ib_user_ioctl_cmds.h        |  17 ++
>>>    include/uapi/rdma/ib_user_ioctl_verbs.h       |  27 ++
>>>    19 files changed, 651 insertions(+), 166 deletions(-)
>>>
-- 
Best Regards,
Yanjun.Zhu