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

[Ira Weiny]

On Fri, 6 Feb 2009 14:47:17 -0500
Hal Rosenstock <hal.rosenstock at gmail.com> wrote:

> 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.

This sounds more reasonable to me, better to suffer now than later...

Ira

> 
> -- Hal
> 
> > Thoughts ?
> >
> > -- Hal
> >
> _______________________________________________
> general mailing list
> general at lists.openfabrics.org
> http:// lists.openfabrics.org/cgi-bin/mailman/listinfo/general
> 
> To unsubscribe, please visit http:// openib.org/mailman/listinfo/openib-general
>