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

[Leon Romanovsky <leon@kernel.org>]

On Wed, Apr 22, 2026 at 01:51:01PM -0300, Jason Gunthorpe wrote:
> 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 have mixed feelings about this. My CQ conversion showed that even a simple
task like creating a CQ umem (numb_of_entries * size_of_entries) ends up full
of creative hacks in various drivers. Because of that, I see real value in
pushing as much logic as possible into the core code instead of duplicating it
across drivers. However, my later attempt to change the QP path made it clear
that creating umems in the core is not a viable goal in the general case.

Another outcome of that work was realizing that CQ resize (and probably MR
rereg as well) becomes messy when we keep the "old" umem around. Splitting
creation and cleanup into different layers probably will going to hurt us
at some point of time.

To summarize:
1. The most practical fix is likely to provide a driver callback to create
   the umem when needed, as you suggested.
2. We should reduce the use of UWH as much as possible in favor of a
   well-defined schema. In the long run, we want to add more umem types,
   and many drivers should work out of the box under that model.
3. Explicit behavior is preferable. If a driver creates something, the
   driver should also clean it up.

I'm not saying no to your proposal, just expressing my thoughts.

Thanks