[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