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 _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
