[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190726132316.GA8695@ziepe.ca>
Date: Fri, 26 Jul 2019 10:23:17 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Michal Kalderon <mkalderon@...vell.com>
Cc: Kamal Heib <kamalheib1@...il.com>,
Ariel Elior <aelior@...vell.com>,
"dledford@...hat.com" <dledford@...hat.com>,
"galpress@...zon.com" <galpress@...zon.com>,
"linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH v6 rdma-next 1/6] RDMA/core: Create mmap database and
cookie helper functions
On Fri, Jul 26, 2019 at 08:42:07AM +0000, Michal Kalderon wrote:
> > > But we don't free entires from the xa_array ( only when ucontext is
> > > destroyed) so how will There be an empty element after we wrap ?
> >
> > Oh!
> >
> > That should be fixed up too, in the general case if a user is
> > creating/destroying driver objects in loop we don't want memory usage to
> > be unbounded.
> >
> > The rdma_user_mmap stuff has VMA ops that can refcount the xa entry and
> > now that this is core code it is easy enough to harmonize the two things and
> > track the xa side from the struct rdma_umap_priv
> >
> > The question is, does EFA or qedr have a use model for this that allows a
> > userspace verb to create/destroy in a loop? ie do we need to fix this right
> > now?
> The mapping occurs for every qp and cq creation. So yes.
>
> So do you mean add a ref-cnt to the xarray entry and from umap
> decrease the refcnt and free?
Yes, free the entry (release the HW resource) and release the xa_array
ID.
Then, may as well don't use cyclic allocation for the xa, just the
algorithm above would be OK.
The zap should also clear the refs, and then when the ucontext is
destroyed we can just WARN_ON the xarray is empty. Either all the vmas
were destroyed or all were zapped.
Jason
Powered by blists - more mailing lists