[openib-general] RE: Failed multicast join withnew multicast module

[Hal Rosenstock]

On Thu, 2006-06-08 at 12:49, Sean Hefty wrote:
> >If this comment is directed at client reregister mechanism, you should
> >note that when this was brought up there was resistance to it based on
> >the recommendation (probably not a strong enough word for this) that SMs
> >be redundant in the subnet. There was a fair bit of anecdotal evidence
> >that this was not how they were being used at the time but it may have
> >been a chicken and egg problem.
> 
> Even with redundant SMs, we wouldn't want them to reassign all of the LIDs in
> the subnet just because of failover.  I don't think of MLIDs as being any
> different.  

Do you mean without redundant SMs (rather than with) ?

There are a couple of things about MLIDs are different:
1. There are very much fewer of them (not necessarily architecturally
but in some implementations)
2. There is lazy deletion of MC groups allowed so the reclamation may be
difficult.

This is not to say it can't be done but there are some hurdles to clear.

> Client reregister support is optional, so what if the node(s) that
> need to re-create the group doesn't support it?

The endport SMAs are claiming they do support client reregistration but
it does take more than that for the endport/node to behave properly.

> What if we started with something like the following compliance statement, and
> tried to add this to the spec?
> 
> An SM, upon becoming the master, shall respect all existing communication 
> in the fabric, where possible.

At the 50K level, I can see where you are coming from and think there is
merit in this but first, I'm not sure I know how to define this and
second, whether that is achievable but could wait to see whether some
definition could be achieved.

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.

-- Hal

> - Sean