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(0x0100000000000000);
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 0x0100000000000000). 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
