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

[Jason Gunthorpe <jgg@ziepe.ca>]

On Wed, Apr 22, 2026 at 04:06:03PM +0200, Jiri Pirko wrote:
> >>Just brain storming, but if we let the driver pass in its uhw
> >>information inot a getter:
> >>
> >>  struct ib_umem *uverbs_attr_get_umem(struct
> >>      uverbs_attr_bundle *attrs, u16 idx,
> >>      u64 uhw_umem_base, u64 umem_len);
> >>
> >>  dbr_umem = uverbs_attr_get_umem(attrs,
> >>                     MLX5_IB_ATTR_QP_DBR, uhw->base, uhw->len);
> >>
> >>Then if the new attribute is provided the uhw is ignored, otherwise a
> >>ib_uverbs_buffer_desc is created from the udata parameters instead.
> >>
> >>Drivers use the normal attr indexes to define their many umems for
> >>something complicated lik QP.
> >
> >Won't this go backwards? I mean, I was under impression that we want to
> >move the umem creation to core. What you suggest is the driver initiates
> >the umem creation. I personally think that it is nicer the way you
> >suggest, since the core is the owner and responsible for cleanup and
> >umems are created upon need.

Well, brainstorming idea. I'd like to hear from Leon too

But if we set the general goals as:

1) All umem creations should have a struct ib_uverbs_buffer_desc at
   the UAPI boundary
2) ib_uverbs_buffer_desc should pass directly to umem code without any
   driver touching it. ib_uverbs_buffer_desc should be the only way to
   create a umem from a driver.
3) Existing UWH umem descriptions must continue to work if the desc is
   not provided, by reforming them into a desc
3) Cleanup and lifecycle should be centralized

I know the initial thinking was coloured by the CQ design which had
the core do everything, but this is echoing back to the old LWN
article "the midlayer mistake":

https://lwn.net/Articles/336262/

And here we are making the basic choice if the midlayer should alloc
the umem and pass it to the driver or the driver should call a library
function to obtain it.

The primary error to correct is pricipally #1, that the drivers did
not have a standardized uAPI surface so it could not be extended to
new forms of umem types.

So, for instance if we restructure the CQ to follow the library
pattern it would have drivers call some

umem = uverbs_attr_get_cq_umem(attrs, cq, uhw->base, uhw->len);

Which will internally obtain the ib_uverbs_buffer_desc:
 1) Directly from the new ib_uverbs_buffer_desc native ATTR_CQ_BUFFER attr
 2) By decoding and converting the existing attrs to
    ib_uverbs_buffer_desc
 3) By converting base/len into a VA type ib_uverbs_buffer_desc

Then just ask the umem layer to build a ib_uverbs_buffer_desc.

We can follow the same pattern for the other cases. If the uAPI has a
logical all-driver umem then a have a uverbs_attr_get_XX_umem() that
uses a core attr

Otherwise use a lower level function and the driver provides a
driver-specific attr to handle its non-general umem.

> >One think. How about the consumption checking? I remember that for my
> >previous attempt on uverb umems you asked to check if each attr was
> >processed or not and in case it was not, yell out at the user.
> 
> Well, I think I can still track consumption per loaded attr. I'm on it.

Yeah, we need to come up with a good story for how the uAPI should
work. As above there are three CQ options, what to do if the user
provides something nonsensical? For CQ I imagine that the helper will
do it internally with if statements.

In general the uattr system doesn't validate that mandatory attributes
where read by the driver. That might be an interesting debug feature
for sure.

I think my original remark was related to the lists, it is much easier
to pass extra items in the list and that would create a uABI problem
down the road if they are silently ignored by today's kernel.

Whereas if the driver has to define mandatory attributes to pass its
unique ib_uverbs_buffer_desc I'm not worried about future ABI because
eveything is now clearly labled and the uattrs system already has a
built in way to reject using a future kernel's driver attribute on an
older kernel.

Jason