Hi James, Sorry for the delay, we had a long weekend.
> > > My opinion is that the create_qp taking generic parameters is > > > correct, only subsequent calls may need to use transport specific > > > calls/arguments. Infact rdma_create_qp uses the ibv_create_qp (now > > > changed to rdmav_create_qp) call internally. > > > > If you want to have a generic rdmav_create_qp() call, there needs to > > be programmatic way for the API consumer to determine what type of QP > > (iWARP vs. IB) was created. > > > > I don't see any way to do that in your patch: > > I think the QP is associated with the transport type indirectly through > the context. It can be queried with ibv_get_transport_type verb. A > renamed rdma_get_transport type would probably suffice. Correct. Opening the device using rdmav_open_device with argument provided by the ULP will provide the context, which is used by subsequent calls to transparently make use of other calls. Either Steve or I can provide the rdmav_get_transport_type() call to return the actual device (transport) type. > > I like the new approach you are taking (keeping 1 verbs library and > > adding rdmav_ symbol names). This change to transport neutral names is > > long overdue. > > > > When you finish with the userspace APIs, I hope you will update the > > kernel APIs as well. Sure. Thanks, - KK _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general