Hi All, This is an old issue that I think we might eventually need to fix. I will appreciate the group thoughts on it:
IBTA defines Multicast Group membership (for routing purposes) to be requested from and maintained by the SA. The "membership" from the SA point of view is of "IB end-ports" not "clients" (but you know all that already). As the SA keeps track of "end-ports" registrations, any "end-port" requesting to leave the group will result with the port to be disconnected from the multicast group (packets will not be forwarded to it). The following sequence is very possible: 1. Two clients (A and B) on the same machine requested to join group G 2. Suddenly client B decided to withdraw its membership (maybe it just cleans up before it leaves). 3. The SA gets B's request to leave the group and disconnect the port 4. Client A got disconnected... It seems the IBTA intent was that the IB driver will be responsible for maintaining the list of clients registered to each group. But the IB core does not track what clients registered (through SA requests) to a particular multicast group. The first client to leave the group causes the rest (of the clients) to be disconnected. My proposal is to provide an API for such registrations at both user and kernel and track the requesting processes. Cleanup is also required both by process and kernel module granularity. BTW: The same API could also handle "Client Reregistration" for multicast groups, such that we could avoid the need to have that code duplicated by every client. But this refers to yet another API that is missing: Report dispatching which deserves its own mail... _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
