[ofa-general] Re: OSM_DEFAULT_SM_KEY byte order

Sasha Khapyorsky sashak at voltaire.com
Mon Jun 2 11:51:51 PDT 2008


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.

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

Sasha



More information about the general mailing list