On Mon, 2008-06-02 at 21:29 +0300, Sasha Khapyorsky wrote: > On 07:06 Mon 02 Jun , Hal Rosenstock wrote: > > > > This came from informal interop testing a while ago. It wasn't invented > > out of thin air. > > IMHO there are not enough information about the case - finally the value > of OSM_DEFAULT_SM_KEY was host byte order (which is obviously wrong), so > it doesn't look for me that the case was fully analyzed.
The value was observed on the IB wire with an analyzer. It was implemented in OpenSM incorrectly. > > > Our own backward compatibility could be solved by configuring sm key > > > (this will work with OpenSM and saquery). > > > > > > Another opinions? > > > > I think that third party SMs are a side issue as this is not sanctioned > > by IBTA and there is other evidence of a vendor SM using SM key. > > > > To me, key is back interop with older OpenSMs (at least for x86 as that > > is the larger part of the installed base) and this is the aspect which > > is sanctioned by IBTA. > > SM_Key value is configurable in OpenSM so we don't really break > interoperability. Well it does by default and that's the behavior we were discussing. This argument cuts the other way too in that it can be "fixed" when needed. > And in longer term '1' seems as much more "friendly" > value than '0x0100000000000000', which entered OpenSM code by mistake I don't think that friendliness is in the same category of factors. Also, it doesn't need to be typed when default except when "wrong". -- Hal > 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
