[ofa-general] [RFC] OpenSM vendor layer
Hal Rosenstock
hal.rosenstock at gmail.com
Thu Feb 12 04:41:28 PST 2009
Sasha,
On 2/7/09, Sasha Khapyorsky <sashak at voltaire.com> wrote:
> On 14:12 Fri 06 Feb , Hal Rosenstock wrote:
>>
>> I'm looking at adding pkey support into the OpenSM vendor layer. The
>> pkey table is a per port structure and is part of ib_port_attr_t. That
>> structure also include num_pkeys. There is only related API:
>> osm_vendor_get_all_port_attr which takes several pointers, the second
>> one is a pointer to a preallocated array of port attributes (memory
>> allocation for that is done by the client). ib_port_attr_t includes a
>> pointer to the pkey table. So the only way this can work is if that
>> allocation is also done by the client which makes that a valid
>> parameter on input (as well as output).
>
> This could be a client choice: if pkey table pointer is initialized as
> NULL osm_vendor_get_all_port_attr() allocates memory and initialize the
> table and its size, otherwise it fills up only provided by client pkey
> table entries.
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 ?
-- Hal
> Sasha
>
More information about the general
mailing list