[openib-general] First Multicast Leave disconnects all other clients

[Hal Rosenstock]

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