Going with #1 is fine by me. Thanks for handling this. -Dave
> On Mar 14, 2016, at 5:01 PM, Hefty, Sean <[email protected]> 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 <[email protected]> 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 >>> [email protected] >>> http://lists.openfabrics.org/mailman/listinfo/ofiwg > _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
