Hi Eitan, On Wed, 2005-11-23 at 02:25, Eitan Zahavi wrote: > 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.
Yes, the end node is responsible for tracking the registrations within the node and fabricating responses when the node does not want to leave. Is delete a different case though ? > 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. This is an implementation issue IMO and applies to other subscriptions too (not just limited to multicast). > 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. Is the API the SA client request itself for this ? Shouldn't the tracking be done there (within sa_query.c) ? > BTW: The same API could also handle "Client Reregistration" for multicast > groups, Client reregistration is for all subscriptions (including ServiceRecords and events as well). > such that we could avoid the need to have that code duplicated by every > client. I'm missing how client reregistration would help here. Can you elaborate ? > But this refers to yet another API that is missing: Report dispatching which > deserves its own > mail... I'm missing the connection between reregistration and report dispatching. -- Hal _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
