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