On Wed, Jul 22, 2015 at 07:58:23PM +0300, Sagi Grimberg wrote:
> On 7/22/2015 7:44 PM, Christoph Hellwig wrote:
> >On Wed, Jul 22, 2015 at 10:34:05AM -0600, Jason Gunthorpe wrote:
> >>>+/**
> >>>+ * ib_alloc_mr() - Allocates a memory region
> >>>+ * @pd: protection domain associated with the region
> >>>+ * @mr_type: memory region type
> >>>+ * @max_entries: maximum registration entries available
> >>>+ * @flags: create flags
> >>>+ */
> >>
> >>Can you update this comment to elaborate some more on what the
> >>parameters are? 'max_entries' is the number of s/g elements or
> >>something?
> >>
> >>>+enum ib_mr_type {
> >>>+ IB_MR_TYPE_FAST_REG,
> >>>+ IB_MR_TYPE_SIGNATURE,
> >>> };
> >>
> >>Sure would be nice to have some documentation for what these things
> >>do..
> >
> >Agreed on both counts. Otherwise this looks pretty good to me.
>
> I can add some more documentation here...
So, I was wrong, 'max_entries' is the number of page entires, not
really the s/g element limit?
In other words the ULP can submit at most max_entires*PAGE_SIZE bytes
for the non ARB_SG case
For the ARB_SG case.. It is some other more difficult computation?
It is somewhat ugly to ask for this upfront as a hard limit..
Is there any reason we can't use a hint_prealloc_pages as the argument
here, and then realloc in the map routine if the hint turns out to be
too small for a particular s/g list?
It looks like all drivers can support this.
That would make it much easier to use correctly, and free ULPs from
dealing with any impedance mismatch with core kernel code that assumes
a sg list length limit, or overall side limit, not some oddball
computation based on pages...
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
