> -----Original Message-----
> From: Sagi Grimberg [mailto:[email protected]]
> Sent: Thursday, July 16, 2015 3:30 AM
> To: Christoph Hellwig
> Cc: Chuck Lever; Jason Gunthorpe; [email protected]; Steve Wise; Or 
> Gerlitz; Oren Duer; Bart Van Assche; Liran Liss;
Hefty, Sean;
> Doug Ledford; Tom Talpey
> Subject: Re: Kernel fast memory registration API proposal [RFC]
> 
> On 7/16/2015 11:07 AM, Christoph Hellwig wrote:
> > On Thu, Jul 16, 2015 at 09:52:44AM +0300, Sagi Grimberg wrote:
> >>>> I suggest to start with what I proposed. And in a later stage (if we
> >>>> still think its needed) we can have a higher level API that hides the
> >>>> post, something like:
> >>>
> >>>> rdma_reg_sg(struct ib_qp *qp,
> >>>>             struct ib_mr *mr,
> >>>>             struct scatterlist *sg,
> >>>>             int sg_nents,
> >>>>             u64 offset,
> >>>>             u64 length,
> >>>>             int access_flags)
> >>>
> >>> I still wonder what ?length? means in the context of a scatterlist.
> >>
> >> Would byte_count be a more explanatory name?
> >
> > What do you even need it for?  The total length is implicitly stored in
> > the S/G list as the list of all elements.
> >
> > What's the offset for?  To allow skipping parts of a S/G list previously
> > mapped?
> >
> 
> These were added when I thought of the pages helper. The memory region
> HW tables consist of physical addresses, a first byte offset, and a
> byte length to indicate when the region ends in the last page.
> 
> However, if we have only sg lists, I agree that the length is derived
> from the sg_list itself and the offset will be sg[0]->offset.
> 
> I can drop it, unless anyone can think of a use-case where a ULP would
> want to register a region with a different offset from sg[0]->offset
> and/or ends before the sum(sg->length).

What if the sg list has to be chunked up due to the device's FRWR pbl depth 
limits?  Or is that handled underneath rdma_reg_sg()?

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to