>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. This probably won't be an issue for a while, since most join requests are limited to select fields of the multicast member record. >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. 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. - 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
