On Mon, 2008-06-02 at 21:51 +0300, Sasha Khapyorsky wrote: > On 11:41 Mon 02 Jun , Hal Rosenstock wrote: > > 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. > > Right, and this leaves questions: for instance if grabbed value was > exactly '0x0100000000000000', I wouldn't see a big chance for such > mistake. Another story would be if grabbed value was something 'non-zero'. > Again, it is unclear for me.
I'm not following what you mean by this but I'm rendering this as moot at this point based on the below. > > > > > 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. > > Yes, it can be "fixed" even now. I'm thinking about permanent solution > and '1' looks like more reasonable default for me. > > > > 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. > > I think it is when we are about default values. > > Also, it doesn't need to be typed when default except when "wrong". > > Right, and "wrong" default right now is on x86. OK, I wrote it backwards again. We're not converging in the least on this and I don't have the time right now to look deeper so I throw in the towel at this point but one last question as maybe I don't understand exactly what you are proposing as a change and also a request related to the answer to that question. Question: What is the expected effect on the wire of these changes (separate cases of little and big endian machines if different) ? Request: If your proposal changes default wire behavior, please make sure this is documented (in more than just the git log) so it stands less of a chance of being missed by users who might not follow all these discussions very closely. -- 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
