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. >From Jason's comment I think just setting the limits fairly large but not excessive is the right approach. Bob
