[openib-general] RE: [RFC] [PATCH 1/2] multicast support for multiple users
Hal Rosenstock
halr at voltaire.com
Thu Apr 6 14:21:39 PDT 2006
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
More information about the general
mailing list