Re: Kernel fast memory registration API proposal [RFC]

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

On 7/13/2015 7:30 PM, Jason Gunthorpe wrote:
> On Fri, Jul 10, 2015 at 12:09:37PM +0300, Sagi Grimberg wrote:
>> Given the last discussions on our in-kernel memory registration API I
>> thought I'd propose another approach to address this.
>
> I assume you can put your new indirect registrations under this API
> without changing the callers?

Correct, it's a bonus. The main idea here is to simplify the API for
ULPs.

>
>>           /*
>>            * Set the SG list in the MR, fail if the sg
>> 	  * list is not well aligned (caller should handle
>> 	  * it) or mr does not have enough room to fit the sg.
>>            */
>>           rc = ib_mr_set_sg(mr, sg, sg_nents);
>> 	 if (rc)
>> 		/* HW does not support - Need to handle it */
>
> I think this call should also do the post.
>
> There seems to be nothing the ULP can customize about the post step
> that needs to be exposed.. and bundling the post allows more
> flexability to implement different schemes without impacting the ULPs.

This is exactly what I don't want to do. I don't think that implicit
posting is a good idea for reasons that I mentioned earlier:

"This is where I have a problem. Providing an API that may or may not
post a work request on my QP is confusing, and I don't understand its
semantics at all. Do I need to reserve slots on my QP? should I ask for
a completion? If we suppress the completion will I see an error
completion? What should I expect to find in the wr_id?"

We're much better off with keeping the post interface in place but
have it much simpler.

Sagi.
--
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