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

[Leon Romanovsky <leon@kernel.org>]

On Sun, Apr 26, 2026 at 07:50:34PM -0300, Jason Gunthorpe wrote:
> 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?

I changed approach and patch planning of my CQ conversion to be
per-driver, see the amount of fixes that it is triggering:
https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=create-cq-entries-v1

However, it remains possible to revert earlier changes.

Thanks

> 
> Jason
>