>What do you think about this flow ? >1. resolve device and port from ip address - synchronous operation > (like at.c resolve_ip) >2. rdma_create_qp (device+port) - modifies qp to init with default pkey index >3. ib_post_recvs(...); >4. cma_connect - asynchronous at, modify qp with correct pkey index, cm_connect
>>It looks like this would work. If a client wanted to create multiple >>connections to the same remote service (for example, to separate control and >>data), then it seems more efficient to move the asynchronous at outside of the >>connect call. >>- Sean Thats a good point. What I had in mind was mainly simplicity for the consumer - save him dealing with another upcall. Maybe caching in at module would make things better, but I agree that for multiple connections to the same remote service, the asynchronous at aproach, seems more appropriate. So ... Does everyone else thinks that we should change the API of a cm abstraction to asynchronous at before connection ? (This should concern mostly the iWAPR guys - Caitlin,Tom etc..) Thanks, Guy _______________________________________________ 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