[ofiwg] fi_trywait and providers
Hefty, Sean
sean.hefty at intel.com
Mon Mar 14 14:01:52 PDT 2016
I didn't realize that this email didn't hit the list until today. The upstream code was updated to option 1.
The main reason to select option 2 or 3 is if we want libfabric 1.3, running with an updated application, to support an older dynamically built provider.
> I have a slight preference for options #1 or #2, but I don't feel strongly
> about it. Other opinions?
>
> -Dave
>
> > On Mar 9, 2016, at 6:24 PM, Hefty, Sean <sean.hefty at intel.com> wrote:
> >
> > The 1.3 libfabric release will contain the fi_trywait call. For
> providers, there are a couple of options available for handling this.
> >
> > - The libfabric core can check that a provider supports the 1.3 API, and
> reject those that don't. This is the easy button.
> >
> > - The fi_trywait call can include a check against the provider's fabric
> ops to see if trywait was implemented. This conditional check would be in
> all fi_trywait paths.
> >
> > - The libfabric core can wrap the provider's fabric ops with its own
> copy of fabric ops. This requires mapping the provider's fabric fid to a
> core fabric fid for the sake of compatibility. This is only needed for
> providers asking for API < 1.3. This is the hard button.
> >
> > - Sean
> > _______________________________________________
> > ofiwg mailing list
> > ofiwg at lists.openfabrics.org
> > http://lists.openfabrics.org/mailman/listinfo/ofiwg
More information about the ofiwg
mailing list