[ofa-general] Re: OSM_DEFAULT_SM_KEY byte order

[Hal Rosenstock]

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