[ofw] saquery & osm vendor AL - ca_names missing from osm_vendor_t ?
sashak at voltaire.com
Tue Feb 3 06:22:48 PST 2009
On 14:11 Mon 02 Feb , Sean Hefty wrote:
> Forwarding to general list and copying Sasha.
> > The Windows OpenSM vendor AL struct 'osm_vendor_t' (defined in
> >opensm\user\include\vendor\osm_vendor_al.h) is missing
> >the entry 'ca_names[UMAD_MAX_DEVICES][UMAD_CA_NAME_LEN]'.
> >saquery.c expects to find ca_names in osm_vendor_t.
> >A couple of observations:
> >1) Windows currently supports a much older version of opensm than what OFED 1.4
> >tools expect.
> >2) saquery uses OpenSM mad interfaces while it 'could' be using libibmad
> > If libibmad from saquery, then OpenSM would not need libibmad references for
> >3) How bad is it to create libibmad dependencies for OpenSM?
Why we need to? Dependencies without reason is not a good thing.
> >4) saquery.c is the only diags pgms (so far) which uses OpenSM MAD interfaces;
> >the rest use
> > libibmad.
> >Most of the OFED diagnostic tools support the cmd-line option '-C ca_name'.
> >This cmd-line input is resolved thru
> >libibmad interfaces.
> >Saquery is no exception in that it expects to match the '-C ca_name' against
> >osm_vendor_t.ca_names. 'ibstat -l' lists
> >CA names.
> >The question becomes how best to resolve the missing ca_names?
> >1) modify saquery to call libibmad interface to get CA names;
That is possible I guess.
> > leaves
> >osm_vendor_t unmodified.
> > So far, saquery is the only diag pgm which uses OSM mad interfaces;
> >expecting ca_names
> > in osm_vendor_t.
OpenSM (osm_vendor_ibumad layer) uses this too for port finding/choosing.
> >2) Modify OpenSM vendor AL osm_vendor_t struct to include CA names and populate
> > from OpenSM code?
How OpenSM in WinOF choose a port to use?
> > Creates libibmad dependencies for opensm.
ca_names by itself doesn't create such dependencies. For instance
osm_vendor_ibumad.c has ca_names and doesn't have any libibmad
More information about the ofw