[openib-general] [Openib-windows] ib_types.h and Win/Linux consolidation

[Hal Rosenstock]

Hi Fab,

On Thu, 2006-07-06 at 15:22, Fabian Tillier wrote:
> On 06 Jul 2006 15:03:02 -0400, Hal Rosenstock <halr at voltaire.com> wrote:
> > Hi Eitan,
> >
> > On Thu, 2006-07-06 at 14:11, Eitan Zahavi wrote:
> > > Hi All,
> > >
> > > I have been approached by several people asking for where does one
> > > gets a header
> > >
> > > file defining the IBTA "wire" protocol.
> > >
> > > My response was: "Ohh we got it all coded in
> > > osm/include/iba/ib_types.h".
> >
> > Actually I was thinking the opposite: that this file was way too big and
> > should be broken up into smaller more manageable pieces.
> >
> > In this usage, I think all is referring to all MADs. ib_types.h supports
> > SM and SA MADs and some other MADs but not all MADs.
> >
> > > "But that thing is so down the tree I do not consider as official" was
> > > the answer.
> >
> > It is currently used by management and utils. utils/linux-user could be
> > moved.
> >
> > What would be the new proposed location for this ?
> >
> > > So the point is clear: If we are missing such a complete IBTA H file
> > > and people are actually looking for where the wire protocol is being
> > > defined why shouldn't we promote ib_types.h to the main include
> > > directory?
> > >
> > > Another issue with ib_types.h :
> > >
> > > Apparently the WinIB (OpenIB windows) version and the Linux version
> > > are a little different.
> > >
> > > Major changes are that the Windows version is a spec 1.1 compliant and
> > > the Linux is supporting version 1.2.
> >
> > Why is Windows 1.1 and not 1.2 compliant ?
> 
> I'm not sure what the deficiencies are here - Windows doesn't have SRQ
> support, or IB 1.2 FMR support,

Linux doesn't have real 1.2 FMR support either.

>  but other than that the on-wire MAD
> stuff should all be fine.
> 
> What's missing?

I'm not familiar with the Windows support so can't comment on the
specifics. Eitan ?

> > > Another difference is the fact some "verbs" or core oriented
> > > definitions found their way into the WinIB version.
> >
> > Another issue is that ib_types.h requires some complib things too.
> >
> > > I hope we can clean those up and have a merged version in place.
> >
> > Perhaps but is this a real requirement ?
> 
> I think that it would be a mistake to share a file like this between
> Windows and Linux, as that requires some sort of abstraction for types
> and packing.  Since abstractions like this won't fly in LKML,

This is not an LKML file. It's a userspace file.

>  it would
> become the burden of the Windows stack to try to get things to be
> portable.  I don't support such an uneven burden being placed on me.

I'm neither for or against this as I do not understand what this means
(e.g. what are the specific changes). In the past, Windows changes have
been rolled back into the Linux user support for OpenSM. However, I am
also wary of any "baggage" here which limits what can be done. As I have
stated before, IMO OpenIB OpenSM is currently accomodating Windows as
opposed to it being a firm requirement that it be supported. I would
prefer the two not to fork but if OpenSM on Linux is impaired for some
reason a split might be necessary. One area where there has been
difficulty in this in the past has been the direct use of pthreads
versus the threading API in complib.

-- Hal

> - Fab