***SPAM*** Re: [ofa-general] [RFC] OpenSM vendor layer
Hal Rosenstock
hal.rosenstock at gmail.com
Thu Feb 12 16:41:40 PST 2009
Sasha,
On Thu, Feb 12, 2009 at 3:00 PM, Sasha Khapyorsky <sashak at voltaire.com> wrote:
> Hi Hal,
>
> On 07:41 Thu 12 Feb , Hal Rosenstock wrote:
>>
>> That's what I originally thought too but I'm not so sure looking at
>> the other vendor layers. For example, osm_vendor_al.c (which I think
>> is used in Windows currently) has the following code in
>> osm_vendor_get_all_port_attr (and other vendor layers except umad are
>> similar):
>>
>> for (port_num = 0; port_num < num_ports; port_num++) {
>> p_attr_array[port_count] =
>> *__osm_ca_info_get_port_attr_ptr(p_ca_info,
>> port_num);
>> port_count++;
>> }
>>
>> and
>>
>> static ib_port_attr_t *__osm_ca_info_get_port_attr_ptr(IN const osm_ca_info_t *
>> const p_ca_info,
>> IN const uint8_t index)
>> {
>> return (&p_ca_info->p_attr->p_port_attr[index]);
>> }
>>
>> so I'm thinking the tables need to be supplied by the underlying
>> vendor library (al, umad, ...). Do you concur ?
>
> It is already supplied by libibumad - by umad_get_ca()
> (ca.ports[i]->pkeys). I think you just need to copy this to
> ib_port_attr_t structure.
Yes but rather than using supplied pointers (as inputs for the per
port pkey/guid tables), the other vendor layers require a large enough
buffer for these tables and set the port pointers appropriately (on
output) rather than supplying these pointers as input parameters. So
if we use these as input, then we definitely break the other vendor
layers.
-- Hal
> Sasha
>
More information about the general
mailing list