[ofa-general] [PATCH] OpenSM/osm_port_info_rcv.c: In __osm_pi_rcv_process_endport, isSMdisabled also indicates that an SM is present so poll SMInfo

[Hal Rosenstock]

On Thu, 2007-04-05 at 15:24, Hal Rosenstock wrote:
> On Thu, 2007-04-05 at 14:24, Roland Dreier wrote:
> >  > Good point. At a minimum, the spec is unclear about this (if they are
> >  > totally separate mechanisms).
> > 
> > When is the spec ever clear? :)
> > 
> > But I think the only interpretation that has a chance at matching the
> > current spec is to say that IsSMDisabled is not directly related to an
> > SM in the NOT-ACTIVE state.
> > 
> > Maybe it's worth asking the WG what the motivation for introducing
> > IsSMDisabled was?
> 
> Yes, I've already done that.

The explanation for the utility of IsSMdisabled is to block an SM from
being able to be started. Quoting one of the architects, the scenario is
as follows:

"Consider a network with heterogeneous elements, hosting different
vendors' stuff, with different vendors' SMs.

But one vendor has a company ID number, used in its GUID, that is
numerically higher than anybody else's. But GUID is always the
tiebreaker in who wins out to be master SM.

If the usually-expected thing happens in an installation and nobody
bothers setting priorities, one of that vendor's SMs always ends up the
master, just because it has a lower company ID. This was deemed Not
Good.

So there at least must be a way to ensure that, even if a node is
capable of running an SM, it doesn't. That's C14-69. It's set by an
unspecified out-of-band means (like a console, or even a dip switch). If
it's disabled, the thing never sticks its head up; it's even prohibited
from asserting IsSM."

Does this make more sense now ?

-- Hal

> -- Hal
> 
> >  - R.
> 
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> 
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general