> > The intent would be to construct a single library containing the > > core functionality -- data transfers, connection establishment, and > > subnet management -- required by most applications. It could target > > combining libibverbs, librdmacm, and libibumad APIs. > > If you are just going to combine all the existing APIs together, then > I'd say no..
Thanks for the input. I wasn't wanting to change the APIs (or require app changes to be more precise). Adding or extending APIs is a possibility, but in the short term I'm more interested in reducing maintenance costs, while making things simpler for users. I want to avoid dependency issues similar to defining struct ibv_path_record. That structure was added to ibverbs, but because the rdmacm and ibverbs are separate packages with no coordination between releases, it was also added to the rdmacm. Arguably, that definition should have been in ibumad, where it doesn't appear at all. I haven't given this much thought - barely more than sending a query to the mail list. At the end of the day, I'm really wanting to reduce the amount of work. :) > But there is so much code out there relying on the existing APIs?? > Plus things like DAPL and CCI trying to be a generic API for rdma. I don't ever see these APIs covering IB management interfaces. > You might want to look at my python-rdma's 'rdma module', which is a > combined API for verbs and umad: > > https://github.com/jgunthorpe/python-rdma > > Where the unification mostly comprises using the same language/API for > talking about paths, end ports, devices and errors. I'll take a look, at least for future reference. - Sean -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
