[ofa-general] opensm: Unsupported attribute = 0xFF02

Hal Rosenstock hrosenstock at xsigo.com
Thu Nov 1 04:56:03 PDT 2007


On Wed, 2007-10-31 at 20:41 -0600, Jason Gunthorpe wrote:
> On Thu, Nov 01, 2007 at 02:24:10AM +0200, Sasha Khapyorsky wrote:
> 
> > What are the reasons? I think complaint SMs should be able to
> > inter-operate, of course not in part of proprietary extensions. At least
> > I am able to run OpenSM with Voltaire SM on one subnet.
> 
> At a minimum how hand off is supposed to work is very vaugely
> specified in the IBA.

SM handover/failover is tested for interop by the IBTA but that's it.
There are known proprietary extensions as well as this being the nose of
the camel being in the tent as in order for this to work well, there is
data replication needed (and no, please don't bring up client
reregistration as the best solution for this).

> Besides, even if hand off wasn't a problem the two SMs would have to
> have very similar ideas on routing, multicast, QOS, services, etc or
> the fabric will be badly disrupted after hand off..

Exactly.

>  Without extensions
> to transfer this live data over before hand off it is unlikely to
> be non-disruptive except in very constrained situations.

Indeed.

> It seems to me the main benifit of the whole standardized mechanism
> (in an interoperability context) is just to help make it so that a new
> sm starting up doesn't just trash the fabric accidentally, and provide
> at least some sensible behavior when two seperate subnets are combined
> into one.
> 
> If you want to test hand over interop joining two operating networks
> is a good way to do it - that is really hard to get right in all of
> the cases :) This was the area where I felt the spec was weakest since
> it really didn't say exactly when during the hand over exchanges each
> SM was in control of the nodes, and exactly what should happen when
> things go wrong was not specified..

Yes, I too believe more work could be and should be done here.

-- Hal

> Jason



More information about the general mailing list