[ofw] Re: [ofa-general] [RFC] 3/5: IB ACM: libibacm

[Ira Weiny]

On Thu, 17 Sep 2009 10:35:39 -0700
"Sean Hefty" <sean.hefty at intel.com> wrote:

> >> #define IB_PATH_RECORD_REVERSIBLE 0x80
> >>
> >> struct ib_path_record
> >> {
> >> 	uint64_t        service_id;
> >> 	union ibv_gid   dgid;
> >> 	union ibv_gid   sgid;
> >> 	uint16_t        dlid;
> >> 	uint16_t        slid;
> >> 	uint32_t        flowlabel_hoplimit; /* resv-31:28 flow label-27:8 hop
> >limit-7:0*/
> >> 	uint8_t         tclass;
> >> 	uint8_t         reversible_numpath; /* reversible-7:7 num path-6:0 */
> >> 	uint16_t        pkey;
> >> 	uint16_t        qosclass_sl;        /* qos class-15:4 sl-3:0 */
> >> 	uint8_t         mtu;                /* mtu selector-7:6 mtu-5:0 */
> >> 	uint8_t         rate;               /* rate selector-7:6 rate-5:0 */
> >> 	uint8_t         packetlifetime;     /* lifetime selector-7:6
> lifetime-5:0
> >*/
> >> 	uint8_t         preference;
> >> 	uint8_t         reserved[6];
> >> };
> >
> >I would prefer to use the structures already defined in ib_types.h...  I
> >understand your not wanting to make ACM dependant on the OpenSM packages so is
> >it time to move ib_types.h out of the OpenSM tree and somewhere more generic?
> >Perhaps libibumad?  This also applies to ib_sa_mad in your 5th patch.
> >
> >OTOH, ib_types.h is a 10K line file with multiple long (>10 lines) inlined
> >functions.  Perhaps it deserves it's own library?
> 
> Defining some of these types in libibumad isn't a bad idea.  Although, WinOF
> actually has 2 copies of ib_types.h (that differ...)  I find using ib_types.h
> painful given its size; separate header files may help.

Yes I was thinking multiple headers.  There seems like there is already some precedent in ib_cm_types.h (although that entire file seems to be enclosed in a #ifndef WIN32 clause?  So am I wrong on this?)

In the end I would like to make ib_types.h just list the specific headers.

Sasha, would you be willing to accept such a patch?  First move ib_types.h to umad and then move the long inline functions into the lib and separate out the remaining header.

Or would you prefer a new library?  I think there is enough code there but I leave it up to you.

Ira

> 
> - Sean
> 


-- 
Ira Weiny
Math Programmer/Computer Scientist
Lawrence Livermore National Lab
925-423-8008
weiny2 at llnl.gov