>> We need to insert in here: >> >> ib_modify_qp(...); /* somehow uses address resolution... */ >> ib_post_recvs(...); >> > >or add a new call to create the qp and modify it to init (an analog to >the socket(2) function).
Sean> This approach seems reasonable to me. Maybe something like: Sean> rdma_create_qp(rdma_addr_info); Sean> Uses the output from the address resolution to create the QP on the Sean> correct device and transitions it to the INIT state. The user can Sean> now post any work requests that they want. For example, with iWarp, Sean> I believe that even send work requests can be posted in the INIT state. 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 Guy _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
