[ofa-general] Re: OSM_DEFAULT_SM_KEY byte order
Hi Hal, On 07:30 Tue 03 Jun , Hal Rosenstock wrote: > > Question: > What is the expected effect on the wire of these changes (separate cases > of little and big endian machines if different) ? On both little and big endian machines default SM Key value on the wire is '1' in network byte order. It changes the behavior of OpenSM on a little endian machine, where by mistake actual value was '0x0100' and leaves it as is on a big endian machines. > 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. Works good for me. 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
[ofa-general] Re: OSM_DEFAULT_SM_KEY byte order
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 '0x0100', 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 '0x0100', 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
[ofa-general] Re: OSM_DEFAULT_SM_KEY byte order
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 '0x0100', 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. > > > > 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 '0x0100', 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. 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
[ofa-general] Re: OSM_DEFAULT_SM_KEY byte order
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 '0x0100', 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
[ofa-general] Re: OSM_DEFAULT_SM_KEY byte order
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. > > 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. And in longer term '1' seems as much more "friendly" value than '0x0100', which entered OpenSM code by mistake. 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
[ofa-general] Re: OSM_DEFAULT_SM_KEY byte order
On Sun, 2008-06-01 at 00:49 +0300, Sasha Khapyorsky wrote: > On 07:52 Thu 22 May , Hal Rosenstock wrote: > > > +#define OSM_DEFAULT_SM_KEY CL_HTON64(1) > > > // > > > /s* OpenSM: Base/OSM_DEFAULT_LMC > > > * NAME > > > > > > > > > , but sort of backward compatibility (currently I know that > > > OSM_DEFAULT_SM_KEY is used with 'osmtest' and 'saquery') could be lost. > > > Is this so important? Ideas? > > > > IMO yes, I think this breaks both backward compatibility and what was > > actually observed from some other SMs during interop testing. > > > > I agree it needs fixing but I think the proper thing is probably more > > like: > > > > #define OSM_DEFAULT_SM_KEY CL_HTON64(0x0100); > > Using value like this we will break on big endian machines where > originally the value is correct. I think that '1' in network byte order > is better (especially in long term) - it is more "native" non-zero > value. Also I found at least one vendor SM which uses 1 as default SM > key in network byte order (and this is expected, I doubt somebody uses > 0x0100). This came from informal interop testing a while ago. It wasn't invented out of thin air. > 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. -- 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
[ofa-general] Re: OSM_DEFAULT_SM_KEY byte order
On 07:52 Thu 22 May , Hal Rosenstock wrote: > > +#define OSM_DEFAULT_SM_KEY CL_HTON64(1) > > // > > /s* OpenSM: Base/OSM_DEFAULT_LMC > > * NAME > > > > > > , but sort of backward compatibility (currently I know that > > OSM_DEFAULT_SM_KEY is used with 'osmtest' and 'saquery') could be lost. > > Is this so important? Ideas? > > IMO yes, I think this breaks both backward compatibility and what was > actually observed from some other SMs during interop testing. > > I agree it needs fixing but I think the proper thing is probably more > like: > > #define OSM_DEFAULT_SM_KEY CL_HTON64(0x0100); Using value like this we will break on big endian machines where originally the value is correct. I think that '1' in network byte order is better (especially in long term) - it is more "native" non-zero value. Also I found at least one vendor SM which uses 1 as default SM key in network byte order (and this is expected, I doubt somebody uses 0x0100). Our own backward compatibility could be solved by configuring sm key (this will work with OpenSM and saquery). Another opinions? 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
[ofa-general] Re: OSM_DEFAULT_SM_KEY byte order
Sasha, On Thu, 2008-05-22 at 17:09 +0300, Sasha Khapyorsky wrote: > Hi, > > I noticed that OSM_DEFAULT_SM_KEY macro is defined and used in host byte > order, this means it has different values on LE and BE machines (as > result we could see some osmtest failures between x86 and G5). The fix > could be trivial: > diff --git a/opensm/include/opensm/osm_base.h > b/opensm/include/opensm/osm_base.h > index 62d472e..7cc2757 100644 > --- a/opensm/include/opensm/osm_base.h > +++ b/opensm/include/opensm/osm_base.h > @@ -117,7 +117,7 @@ BEGIN_C_DECLS > * > * SYNOPSIS > */ > -#define OSM_DEFAULT_SM_KEY 1 > +#define OSM_DEFAULT_SM_KEY CL_HTON64(1) > // > /s* OpenSM: Base/OSM_DEFAULT_LMC > * NAME > > > , but sort of backward compatibility (currently I know that > OSM_DEFAULT_SM_KEY is used with 'osmtest' and 'saquery') could be lost. > Is this so important? Ideas? IMO yes, I think this breaks both backward compatibility and what was actually observed from some other SMs during interop testing. I agree it needs fixing but I think the proper thing is probably more like: #define OSM_DEFAULT_SM_KEY CL_HTON64(0x0100); -- 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
