[ofw] Re: saquery & osm vendor AL - ca_names missing from osm_vendor_t ?

Yevgeny Kliteynik kliteyn at dev.mellanox.co.il
Sun Feb 8 14:36:43 PST 2009


Yevgeny Kliteynik wrote:
> Hi Stan,

Oops... Looks like I was having a problem with my mail client.
By now my response is partially outdated...

-- Yevgeny

> Adding Sasha (OFED management maintainer)
> and the openib mailing list.
> 
> Stan C. Smith wrote:
>> Hello,
>>   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.
> 
> Correct. Windows OpenSM is a ported pre-OFED 1.2 OpenSM with couple of 
> minor fixes.
> 
>> 2) saquery uses OpenSM mad interfaces while it 'could' be using 
>> libibmad interfaces.
> 
> By "OpenSM mad interfaces" you mean libosmvendor?
> 
>>    If libibmad from saquery, then OpenSM would not need libibmad 
>> references for Windows.
> 
> Not sure what you mean here. You mean removing libibmad dependency from 
> saquery?
> 
>> 3) How bad is it to create libibmad dependencies for OpenSM?
> 
> Pretty bad. I don't think we should add a new dependency unless there's a
> really good reason for it.
> 
>> 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; 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.
>>
>> 2) Modify OpenSM vendor AL osm_vendor_t struct to include CA names and 
>> populate ca_names
>>    from OpenSM code?
> 
> I'd say that this option is much better.
> 
>>    Creates libibmad dependencies for opensm.
> 
> But it doesn't have to. Can IBAL expose some function to get these names,
> so that Win osmvendor will use this function instead of libibmad?
> 
> Also, Linux osmvendor doesn't have libibmad dependency.
> It uses umad function umad_get_cas_names() to obtain the CA names.
> I know that there is a Windows version of umad, but I don't know what is
> its status. If we *have* to add an additional dependency, then it should
> be libibumad and not libibmad.
> 
> At some point in the future we would really want to have the new version
> of OFED OpenSM ported to WinOF. If there will be a match between Linux and
> Windows libraries, then the whole vendor concept can be simplified and
> there won't be a need to have a separate vendor for IBAL. The things
> that would be different are platform-dependent issues like threads, locks,
> syslog, but not IB-related code.
> 
> -- Yevgeny
> 
> 
>> Comments?
>>
>> Thanks,
>>
>> Stan.
>>
>>
>>
>>
> 
> _______________________________________________
> ofw mailing list
> ofw at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
> 




More information about the ofw mailing list