Regarding capability #defines in provider-specific headers for extensions ..
What if the application is compiled against one of these headers, but is later linked with a (new) provider .so on the system that has removed the extension. Is a provider library allowed to remove extensions, or must the extension symbols be maintained? Is this simply the cost, or risk, with using provider extensions and the application should expect to have to recompile?
Also, how do you avoid the possibility of SFI being (effectively) forked if a popular provider exposes most of its optimizations via provider extensions and applications are forced to use these extensions to get the expected performance on this provider's fabric?
Thanks.
-----Original Message-----
From: ofiwg-bounces at lists.openfabrics.org [mailto:ofiwg-bounces at lists.openfabrics.org] On Behalf Of Reese Faucette (rfaucett)
Sent: Sunday, November 2, 2014 11:34 PM
To: Jeff Squyres (jsquyres)
Cc: ofiwg at lists.openfabrics.org
Subject: Re: [ofiwg] lifabric provider extensions
Well, I am throwing it out as a candidate for "standard / common practice" - I have not actually tried implementing against it or given it the depth of analysis to confidently advocating for it yet. I think that with the "group-think" from this list we can come up with something pretty good.
Yes, probably worth also standardizing on the #defines app src code would look for regarding extensions.
-r
> -----Original Message-----
> From: Jeff Squyres (jsquyres)
> Sent: Saturday, November 01, 2014 4:29 AM
> To: Reese Faucette (rfaucett)
> Cc: ofiwg at lists.openfabrics.org
> Subject: Re: [ofiwg] lifabric provider extensions
>
> Just to be clear: you're advocating that this become the standard /
> common practice, right? I.e., that "fi_<provider_name>.h" be standard
> form for header files for provider-provided extensions, right?
>
> Hence, configure-providing software can do things like AC_CHECK_HEADER
> to see if various provider extensions are available.
>
> Is it worth having some additional #define's of a common form in
> fi_<provider_name>.h to identify what objects have extensions? E.g.,
> fi_xyzzy.h could "#define FI_XYZZY_AV_OPS 1" so that and app can
> programmatically know that fi_ops_av_xyzzy exists.
>
>
>
> On Oct 31, 2014, at 1:07 PM, Reese Faucette (rfaucett)
> <rfaucett at cisco.com>
> wrote:
>
> > I have this idea of how providers might add calls in the rare event
> > its
> needed, but would like to run it by the list for comments.
> > Let's say provider xyzzy supportsa new call AV-related call,
> "fi_av_xyzzy_add_flux()". The would be a new header "fi_xyzzy.h" and
> "xyzzy_av.c" as shown below.
> >
> > Does this seem sane? I think the "version" passed to fi_getinfo can
> > be
> used to deal with fi_ops_av growing wrt. Backwards compatability.
> >
> > Thanks,
> > -reese
> >
> > ======= fi_xyzzy.h ========
> >
> > struct fi_ops_av_xyzzy {
> > struct fi_ops_av base_ops;
> > int (*add_flux)(struct fid_av *av, ssize_t flux_value); };
> >
> > static inline int
> > fi_av_xyzzy_add_flux(struct fid_av *av, ssize_t flux_value) {
> > return ((struct fi_ops_av_xyzzy *)av->ops)->
> > add_flux(av, value);
> > }
> >
> > ====== xyzzy_av.c ==========
> >
> > struct fi_ops_av_xyzzy xyzzy_av_ops = {
> > .base_ops = {
> > .size = sizeof(struct fi_ops_av_xyzzy),
> > .insert = xyzzy_av_insert,
> > ...
> > },
> > .add_flux = xyzzy_av_add_flux; };
> >
> > int xyzzy_av_open(...)
> > {
> > ...
> > av->ops = (struct fi_ops_av *)&xyzzy_av_ops;
> > ...
> > return 0;
> > }
> >
> > _______________________________________________
> > ofiwg mailing list
> > ofiwg at lists.openfabrics.org
> > http://lists.openfabrics.org/mailman/listinfo/ofiwg
>
>
> --
> Jeff Squyres
> jsquyres at cisco.com
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
ofiwg mailing list
ofiwg at lists.openfabrics.org
http://lists.openfabrics.org/mailman/listinfo/ofiwg