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 > [email protected] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
