> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
