[ofiwg] fi_trywait and providers

[Dave Goodell (dgoodell)]

Going with #1 is fine by me.  Thanks for handling this.

-Dave

> On Mar 14, 2016, at 5:01 PM, Hefty, Sean <sean.hefty at intel.com> wrote:
> 
> 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
>