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

Jason Gunthorpe
2026-04-26T22:50:37Z

On Sun, Apr 26, 2026 at 04:53:40PM +0300, Leon Romanovsky wrote:
> > 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.

So, I think making small steps that upgrade all drivers will be
helpful here.

If we can get all drivers calling the same attrs function and giving
their uhw parameters that is a good step closer to being able to put
that in a function if that is how things need to go down the road.

And it does #2..

Not sure about #3, we already moved toward core destroying umems it
may not be a good idea to try to undo that now.. But maybe we just
keep that for CQ and leave QP as driver managed?

Jason