[ofa-general] Re: OSM_DEFAULT_SM_KEY byte order

[Hal Rosenstock]

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