On Fri, Jun 25, 2021 at 12:13:57AM -0500, Bob Pearson wrote: > On 6/24/21 4:21 PM, Shoaib Rao wrote: > > > > On 6/18/21 4:25 PM, Jason Gunthorpe wrote: > >> On Fri, Jun 18, 2021 at 01:58:48PM -0500, Bob Pearson wrote: > >>> On 6/18/21 11:33 AM, Jason Gunthorpe wrote: > >>>> On Thu, Jun 17, 2021 at 10:56:58PM -0500, Bob Pearson wrote: > >>>> > >>>>> It isn't my call. But I am in favor of tunable parameters. -- Bob Pearson > >>>> Can we just delete the concept completely? > >>>> > >>>> Jason > >>>> > >>> Not sure where you are headed here. Do you mean just lift the limits > >>> all together? > >> Yes.. The spec doesn't have like a UCONTEXT limit for instance, and > >> real HW like mlx5 has huge reported limits anyhow. > > > > These limits are reported via uverbs, so what do we report without current applications. Creating pool also requires limits but I guess we can use something like -1 to indicate there is no limit. I would have to look at all the values to see if we can implement this. > > > > Shoaib > > > > > >> > >> Jason > > The object create in pools (rxe_alloc_locked) just calls kzalloc for > objects allocated by rxe and checks the limits. For objects > allocated by rdma-core (__rxe_add_to_pool) it just checks the > limits. The only place where the limit really matters is when a pool > is indexed (RXE_POOL_INDEXED). Then there is a bitmask used to > allocate the indices for the objects which consumes one byte for > each 8 objects. Use an ida or xarray instead? Jason
