[ofa-general] Re: OSM_DEFAULT_SM_KEY byte order

[Hal Rosenstock]

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(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).

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