Re: Kernel fast memory registration API proposal [RFC]

[Christoph Hellwig <hch-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]

On Wed, Jul 15, 2015 at 11:33:39AM +0300, Sagi Grimberg wrote:
> Umm, I think this can become weird given all other primitives have
> ib_ prefix. I'd prefer to keep that prefix to stay consistent, and have
> an incremental change to do it for all the primitives (structs & verbs).

Fine with me, we're getting into bikeshedding here anyway..

> >I'd also get rid of the horrible style of using structs even for simple
> >attributes.
> 
> The reason I thought an attr struct would benefit is that it can be
> easily extended without changing every single caller (we might have
> more attributes in the future?). Plus, it is consistent with QP and
> CQ creation.
> 
> If you feel strongly about it, I can change it.

It's a very hard to follow API, and extending callers for new features
is not an issue but actually a "feature" as it requires / encurages
a review of the caller to check how the new feature fits in for them.

> >To support FRMs if we care enough we'd create a purely in-memory MR
> >in rdma_create_mr and then map it to ib_fmr_pool_map_phys with a helper
> >that the driver can call instead of rdma_init_mr_wr.
> >
> 
> Lets take it at a later stage.

For the API to be useful it should cover the existing users.  I think
the FMR pool support is fairly trivial, so if you come up with he FR
version I'll volunteer to add it.
--
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