[openib-general] Re: Failed multicast join withnew multicast module

[Sean Hefty]

Hal Rosenstock wrote:
> 2. There is lazy deletion of MC groups allowed so the reclamation may be
> difficult.

I'm not familiar with the switch programming.  Does the SM set the entire 
MulticastForwardingTable for a switch every time a new group is created, or a 
new member joins?  If the SM loses track of all multicast groups, how are the 
stale groups on the switches deleted?

> The endport SMAs are claiming they do support client reregistration but
> it does take more than that for the endport/node to behave properly.

My original plan was to have the ib_multicast module rejoin all groups, but 
since the MLIDs can change I can't see any way to handle reregistration safely 
without involving the application.  My latest changes are just to report errors 
on existing multicast groups on an affected port.

> I know it is a conceptual rather than actual compliance. One issue would
> be defining what it means to repect all existing communication. Then we
> would need to look at whether that was feasible or not and perhaps
> rescope what it means to a set of things achievable. Another issue would
> be defining where it is possible or not. If that is totally vendor
> dependent, then this would have no substance to it. It is largely a
> matter of being a "better" SM.

We could use the phrase, "except where such communication is no longer 
realizable" instead of "where possible".  Where unrealizable means impossible 
because the communication uses properties that are physically impossible to 
achieve given the hardware configuration of the subnet.  (See bottom of page 910 
of the spec.)

If an SM could just query switches for their MulticastForwardingTables or the 
end nodes, would we be able to avoid these issues?

- Sean