> > > +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 didn't find the comment confusing. Just the choice to let a test app drive the design.
--
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
