>If the connect call succeeds in establishing a connection, the ULP's >QP should be ready for posting work requests. This simplifies the ULP >considerably. > >The API should not create the QP. That would create race conditions >for certain protocols. For example, consider a protocol in which the >first message was a send from the server to the client. To properly >implement such a protocol, the client must post a receive work request >before initiating a connection.
Thanks for the clarification. This is similar to what I was thinking as well. I guess we should note that in order to post receives to the QP, it at least needs to be in the INIT state. Would this be done by the CM abstraction or the user? For IB, the following fields need to be set when transitioning to INIT: enable RDMA, PKey index, and physical port. Is the idea that the user calls connect() and then receives a single callback indicating that the connection has been established? If so, then the user may need to modify the QP to the INIT state, which would require some knowledge already of the path. We would also need to be clear on whether the QP is expected to be in the INIT state before connect is called, or if it could be in any arbitrary state. The other alternative is to provide multiple callbacks during connection establishment. - Sean _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
