[openib-general] RE: [RFC] [PATCH 1/2] multicast support for multiple users

[Hal Rosenstock]

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