> On 10/8/2014 4:54 PM, Steve Wise wrote: > >>>> @@ -1056,6 +1067,14 @@ struct ib_send_wr { > >>>> int access_flags; > >>>> struct ib_sge *prot; > >>>> } sig_handover; > >>>> + struct { > >>>> + u64 iova_start; > >>>> + struct ib_indir_reg_list *indir_list; > >>>> + unsigned int indir_list_len; > >>>> + u64 length; > >>>> + unsigned int access_flags; > >>>> + u32 mkey; > >>>> + } indir_reg; > >>> > >>> What is mkey? Shouldn't this be an rkey? > >> > >> mkey means memory key. I can change it to rkey if that > >> is clearer. > > > > Is it valid to use an lkey here? Or is an rkey required? If an rkey is > > required, then I'd say it is clearer to name it rkey (and > > that aligns with the fastreg struct). > > > > It is valid. The memory key depends on the use case. > In case a client want to send an rkey to a peer, it will register using > rkey. In case a server wants to transfer data from it's local buffer > it will register using lkey. > > So I didn't impose a specific key here - this is why I chose mkey. > > I can modify it to rkey to mimic the well known fastreg, but its not > a must. >
If both local-only and local/remote are valid, then I agree mkey is good. I was thinking an application wouldn't need this API for local-only registrations; it could just use the local dma lkey and a bus address in the sge. But perhaps the indirect fastreg allows a deeper sgl than is supported by providers via the SEND/READ/WRITE/RECV work requests... Steve. -- 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