Re: ib mad definitions

[Ira Weiny <weiny2-i2BcT+NCU+M@public.gmane.org>]

On Tue, 19 Oct 2010 20:28:18 -0700
Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> wrote:

> On Tue, Oct 19, 2010 at 06:12:56PM -0700, Ira Weiny wrote:
> 
> > I am all for "cleaner, more capable..." but why incompatible?  If we want to
> > start fresh and then convert OpenSM later, fine.  But _don't_ forget to go
> > back and convert OpenSM, because if you leave ib_types.h out there someone is
> > going to use it and we are back to where we started...  :-(  Same for ibmad,
> > when these definitions become available in umad, mad can be simplified.
> 
> ib_types.h should not be installed in /usr/include, stop doing that
> and that risk goes away.

That is one way to solve it, but only after those definitions (or equivalent) are available in /usr/include.

> 
> ibmad can't really be changed, it is system library with a defined
> API. Maybe ibmad.2 or something, I don't know. I tried to use some of
> the PR APIs in it, and I've found them not useful :(

ibmad.2 is the way to go.  I have expressed my distaste for ibmad in the past and I agree, it is too established to be changed.  But I have not had the time.  Mainly I am trying to support Sean who has the time.

Ira

> 
> For instance we can't just abandon the mad_get_fields approach because
> we have real, usuable field access in umad, it has to stay.
> 
> > Right now there are 3 headers I find path record in.
> 
> > libibverbs: sa.h
> 
> This isn't a MAD path record, this is the kernel version, which is
> unpacked. What we really needs is MAD 2 kernel and vice versa
> conversion in a library. I already have code that does this in
> several places :(
> 
> > libibmad: mad.h
> 
> You mean mad_get_fields IB_SA_PR_DGID_F, etc? It doesn't even have all
> the fields :(
> 
> > opensm: ib_types.h
> 
> Yep.
>  
> > Node type is defined in:
> > 
> > libibverbs: verbs.h
> > opensm: ib_types.h
> > libibmad: mad.h
> > 
> > I could go on.
> 
> Keep in mind that for the most part libibmad is someones attempt to
> make a set of accessors and structures for mads. It is incomplete. It
> is largely unusable. I certainly haven't been able to use its PR
> structure parsing functions for any real app. Was it just pulled out
> of opensm? I don't know, I'd just as soon see that part of it be
> discarded, and a complete set of structures added to umad.
> 
> opensm has unique problems because they want to remain independent of the
> OFA stack, I don't think they have a choice but to duplicate.
> 
> Jason


-- 
Ira Weiny
Math Programmer/Computer Scientist
Lawrence Livermore National Lab
925-423-8008
weiny2-i2BcT+NCU+M@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html