From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Steve Wise" Subject: RE: Kernel fast memory registration API proposal [RFC] Date: Thu, 16 Jul 2015 09:25:15 -0500 Message-ID: <000b01d0bfd3$3b7e1df0$b27a59d0$@opengridcomputing.com> References: <20150713163015.GA23832@obsidianresearch.com> <55A4CABC.5050807@dev.mellanox.co.il> <20150714153347.GA11026@infradead.org> <55A534D1.6030008@dev.mellanox.co.il> <20150714163506.GC7399@obsidianresearch.com> <55A53F0B.5050009@dev.mellanox.co.il> <20150714170859.GB19814@obsidianresearch.com> <55A6136A.8010204@dev.mellanox.co.il> <55A754BC.6010706@dev.mellanox.co.il> <20150716080702.GD9093@infradead.org> <55A76B84.30504@dev.mellanox.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <55A76B84.30504-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> Content-Language: en-us Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: 'Sagi Grimberg' , 'Christoph Hellwig' Cc: 'Chuck Lever' , 'Jason Gunthorpe' , linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, 'Or Gerlitz' , 'Oren Duer' , 'Bart Van Assche' , 'Liran Liss' , "'Hefty, Sean'" , 'Doug Ledford' , 'Tom Talpey' List-Id: linux-rdma@vger.kernel.org > -----Original Message----- > From: Sagi Grimberg [mailto:sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org] > Sent: Thursday, July 16, 2015 3:30 AM > To: Christoph Hellwig > Cc: Chuck Lever; Jason Gunthorpe; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html