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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Thu, Apr 16, 2026 at 03:34:05PM +0200, Jiri Pirko wrote:

> >Get umem from the new attribute if available or fallback to existing
> >attributes:
> >
> >-       umem = uverbs_create_cq_get_umem(ib_dev, attrs);
> >-       if (IS_ERR(umem)) {
> >-               ret = PTR_ERR(umem);
> >-               goto err_event_file;
> >-       }
> >+       if (uverbs_attr_is_valid(attrs, UVERBS_ATTR_CREATE_CQ_BUFFER)) {
> >+               ret = uverbs_get_umem(&umem, attrs, UVERBS_ATTR_CREATE_CQ_BUFFER);
> >+               if (ret)
> >+                       goto err_event_file;
> >+       } else {
> >+               umem = uverbs_create_cq_get_umem(ib_dev, attrs);
> >+               if (IS_ERR(umem)) {
> >+                       ret = PTR_ERR(umem);
> >+                       goto err_event_file;
> >+               }
> >+       }
> >
> >Drivers don't need to change.
> 
> uverbs_create_cq_get_umem only works with legacy attrs. Not that
> interesting. How do you propose to handle other umems, when uverb
> supports multiple umems (like + DRB umem for create CQ)? I'm
> particularly interested in consumption validation and life-cycle
> management (that is a bit trickier for create QP).

Having a standardized attrs getter for a umem is sort of interesting,
but you are right it doesn't address the the lifecycle, the driver
would still have to keep track of the returned umem.

The interest in working on the umems was two parts
 - Make more drivers accept more kinds of umems (ie dmabuf) 
   by getting them out of the driver data
 - Have the core code participate more in managing the lifecycle of
   the umem to avoid driver duplication

The latter was easier on the cq/mr cases but QP is quite a bit more
complicated.

Jason