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

[Smith, Stan]

Hello all,
  My initial query, sadly somewhat confusing w.r.t. my confusion of mad vs. umad interfaces, was asking if it is permissible for the Windows OpenSM vendor-ibal to have a dependence on umad?

In order for the OFED saquery to work correctly in the Windows environment, saquery code expects the osm_vendor_t struct to have the embedded ca_names[UMAD_MAX_DEVICES][UMAD_CA_NAME_LEN] definition.
This definition creates two umad dependencies:
  1) #define UMAD_MAX_DEVICES + #define UMAD_CA_NAME_LEN
  2) a umad_get_cas_names() call to populate the osm_vendor_t.ca_names struct.

The current version of OpenSM vendor_umad already has the umad dependency, so it seemed somewhat reasonable to introduce this dependency in Windows OpenSM.

This OpenSM change is considered temporary until such a time as we find a Windows opensm maintainer who has cycles to move Windows OpenSM forward to the current OFED OpenSM code base; Ishai has stated you are unavailable due to other project responsibilities.
Much of Sean's WinVerbs/WinMAD/libmad/libumad Windows work provides the necessary infrastructure to make porting the latest OFED OpenSM much easier.
I see there is an svn branch where someone is working on OpenSM? Any ideas as to what's going on here?

My proposal for the Windows OpenSM code base is to add ca_names[UMAD_MAX_DEVICES][UMAD_CA_NAME_LEN] to OpenSM vendor-ibal definition of osm_vendor_t and a call to umad_get_cas_names() to populate the osm_vendor_t.ca_names struct for.

Comments?

Thanks,

Stan.




Yevgeny Kliteynik wrote:
> 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