On Tue, Dec 08, 2015 at 01:17:48PM -0600, Sean Hefty wrote: > > > > +struct ib_pd *rvt_alloc_pd(struct ib_device *ibdev, > > > > + struct ib_ucontext *context, > > > > + struct ib_udata *udata) > > > > +{ > > > > + struct rvt_dev_info *dev = ib_to_rvt(ibdev); > > > > + struct rvt_pd *pd; > > > > + struct ib_pd *ret; > > > > + > > > > + pd = kmalloc(sizeof(*pd), GFP_KERNEL); > > > > + if (!pd) { > > > > + ret = ERR_PTR(-ENOMEM); > > > > + goto bail; > > > > + } > > > > + /* > > > > + * This is actually totally arbitrary. Some correctness tests > > > > + * assume there's a maximum number of PDs that can be allocated. > > > > + * We don't actually have this limit, but we fail the test if > > > > + * we allow allocations of more than we report for this value. > > > > + */ > > > > > > Why not trap this in user space, rather than forcing the kernel to > > support some test program? > > > > > > > What do you mean "trap this in user space"? This code is not supporting > > any > > particular test program. > > > > If users try and allocate more protection domains then are advertised then > > an > > error should be returned. > > > > Perhaps the comment should be removed if it is confusing? > > There is no theoretical limit on the number of PDs, or likely most other > resources. So why define and enforce an arbitrary limit? The justification > given was that some test program would fail. If there's a concern about that > test program passing, then enforce the limit in user space. I did not interpret this as being driven by a test but rather by the IBTA spec. This may be pedantic but, wouldn't it be confusing from a user POV to see an advertised limit but then not be constrained by it? I'm not opposed to setting this limit arbitrarily high, but I still think the implementation should enforce that limit. > > I didn't find the comment confusing. Just the choice to let a test app drive the design. Perhaps "confusing" is the wrong word. But I did not interpreted the comment as saying that the implementation was driven but a test program. Ira -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html