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

[Hal Rosenstock]

On Thu, 2007-11-01 at 05:56 +0200, Sasha Khapyorsky wrote:
> On 20:41 Wed 31 Oct     , 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.
> 
> It is at least basically described in the IBA - with exchanging SMInfo.
> 
> > 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
> 
> In worst case the routing tables and QoS setups could be reconfigured
> from scratch (just as if it could be first SM run), and all SA related
> things could be rerequested with ClientReregistration bit.

Routing tables are usually driven by algorithms (all beyond the spec)
rather than table loading.

Don't trivialize management data in a large subnet. It is potentially a
large amount of configuration which people try hard to avoid until they
no longer have a choice.

I view client reregistration as a workaround for this very issue. I am
regretting pushing that into the spec for that purpose.

> And sure, some configurations (partitions, QoS, routing, etc.) can be
> not synchronized for SMs, but then the differences in a fabric setups
> should be expected results.

Is that really acceptable for a real customer ?

-- Hal

> And I'm not about "how fast and efficient it is" and even not about
> "interoperability" bugs in various implementations.
> 
> > or
> > the fabric will be badly disrupted after hand off.. Without extensions
> > to transfer this live data over before hand off it is unlikely to
> > be non-disruptive except in very constrained situations.
> > 
> > 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..
> 
> Ok, so we are not about "impossibility" to do this... Just current lack
> of standardization makes it hard to do handover properly?
> 
> Sasha
> _______________________________________________
> 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