[ofa-general] Re: [RFC] OpenSM vendor layer

[Hal Rosenstock]

On Fri, Feb 6, 2009 at 2:12 PM, Hal Rosenstock <hal.rosenstock at gmail.com> wrote:
> Hi,
>
> 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). Similarly for num_pkeys so the
> vendor layer doesn't go past the end of the supplied table. So both
> num_pkeys and p_pkey_table in that struct need to be in/out
> parameters. num_pkeys could always be returned as the total number of
> pkeys for the port when num_pkeys is set to 0 on input.
>
> Similar thing is true for gid table in ib_port_attr_t.
>
> I'm also not sure which vendor layers are important. I don't see how
> to fix them all (e.g. osm_vendor_al.c is one, there are some others)
> as some of them appear to do a straight memory to memory copy of the
> ib_port_attr_t structure (others are OK and fixable).
>
> The only other alternative I see is to change this API and possibly
> this structure which is way more disruptive and risky (especially with
> the inability to test anything but one of the vendor layers).

Actually, although more disruptive, it might be cleaner (and safer in
the long run) to add to the vendor API. There could be additional osm
vendor APIs for pkeys and gids and these could return some suitable
IB_ error from ib_types in vendor layers where they are unimplemented.
IB_UNSUPPORTED looks good to me. I'm likely to head down this approach
unless I hear otherwise.

-- Hal

> Thoughts ?
>
> -- Hal
>