amith rajith mamidala wrote:
1. Does the API which waits for join to complete ensure that the multicast forwarding tables in the switches have been updated. This is one of the main problems that we had studied:
The join is asynchronous. Completion of the join would not be reported until the switch tables had been updated. (Note that this is really an SA issue outside the scope of the local code).
2. I am not clear on how to access the QP associated with the cm_id for multicast. This includes posting the receive descriptors etc.
rdma_create_qp() returns a struct ibv_qp *. You would access the QP just as you normally would for posting receives or sends to non-multicast endpoints.
3. If an multicast address is already used by an application running on the cluster and if another request is made by a different application with the same multicast address, does this generate an error? From the API, it looks like the application has to manage this aspect,
If two applications make a request to join the same group, they simply both join the same group. One of the key points to the proposal is that a multicast group is identified by an IP address from a user's perspective. MCMemberRecords are abstracted from the user.
- 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
