On Thu, 2006-04-06 at 17:01, Sean Hefty wrote: > >1. My main initial comment is that I think that cmp_rec needs to be more > >complicated that the matching which is there. The selectors include > >things like greater than, less than, and largest available in addition > >to equal to which is what is supported there now. I'm not sure whether > >any of this is used right now so may not be an issue for IPoIB. > > I will review the spec to see where the checks need to be enhanced.
There's also code in opensm/osm_sa_mcmember_record.c that you can peruse. > This > probably won't be an issue for a while, since most join requests are limited > to > select fields of the multicast member record. Agreed. > >2. The other comment is I didn't yet follow how multiple joins of > >different JoinStates are handled. I can see there are different slots in > >the groups but I didn't see whether all the joins go out on the wire > >(one per JoinState) or whether there is some "promotion"/"demotion" of > >these. > > The code uses a promotion/demotion mechanism based on a reference count of > membership types. The restriction is that only a single request per group is > active at a time. Meaning only one of the membership types is active outside the node ? If so, that seems right as long as the order of precedence is correct. How does the change in precedence occur ? Is it a leave followed by the new join or the new join followed by the old leave ? > All join requests are queued to a pending list. If a request can be met with > the current join state of the group, it is added. If not, then a request is > sent to promote the group. Leave requests are handled differently, but result > in demotion. Sounds right. Thanks. -- 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
