Re: Kernel fast memory registration API proposal [RFC]

[Sagi Grimberg <sagig-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org>]

On 7/11/2015 1:39 PM, Christoph Hellwig wrote:
> On Fri, Jul 10, 2015 at 12:09:37PM +0300, Sagi Grimberg wrote:
>> And then provide helpers to populate the MR with generic kernel
>> structures such as struct scatterlist (for scsi and other ULPs),
>> struct page (for NFS) or struct bio_vec (for block ULPs later on).
>
> Please stick to struct scatterlist for now.  Future block ULPs
> will use that as well as the only way you can do a multi-page
> DMA mapping is the scatterlist.

I see.

> A page is just a subset of an SGL, and we can map a page using a one element SGL trivial,
> as we do in lots of places.
>

But won't that make sunrpc rdma consumers to hold an extra scatterlist
just for memory registration?

Chuck, Would a scatterlist API make life easier for you?

>> We can consider moving the iova and length to the population helpers.
>> Wasn't sure what is better...
>
> Move it to the population helpers.  The walk done in them is used to
> generate those values anyway, so there is no need to expose them in
> any sort of public API.

Yea, makes sense.

>  I'd also move the access_flags initialization to the helpers,
> leaving post to do just that:  post an alredy initialized mr structure.

I can do that, but it's not really related to the sg.

Say a consumer wants to register an SG for peer X and then change
access permissions for peer Y. There is no real reason to re-init
the mappings right?
--
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