[ofiwg] utility component/providers

[Sung-Eun Choi]

>From the perspective of a provider writer, I like the last option
where the core providers can pick and choose utility components.  I'm
not sure what granularity you were thinking of, but it would be nice
for it to be coarser than the way utility providers are today.  For
example, on Cray XC systems the native atomic operations are only for
32- and 64-bit operands, so it'd be nice to pick up a "utility
version" for the other atomic data types.

>From the perspective of a client of libfabric (which is what I am of
late), I would like some way to know when a utility (or maybe simply
non-native) version of some operation is begin used.  Using the
example of atomics again, if I knew that the atomic implementation was
non-native, I would chose to use my own implementation (at least for
the Chapel port to libfabric).

-- Sung

On Tue, Feb 21, 2017 at 07:29:48PM +0000, Hefty, Sean wrote:
> There was a prior discussion about utility providers reporting the underlying provider that they use.  A proposal that introduced a 'comp_list' field into the fabric attributes was added to help with this.  But, of course, this doesn't quite work...
> 
> The utility providers plug into the framework the same way core providers do.  So they are subject to provider filtering (e.g. setting prov_name or FI_PROVIDER).  Additionally, they use their own provider structure for log messages.  Utility providers include an 'ofi-' prefix, so it's possible to special case.  But we need to figure out how we want users to deal with their existence wrt filtering and logging.
> 
> For discussion purposes, I've thought about adding an FI_UTILITY environment variable as a peer to FI_PROVIDER.  But this is conceptually equivalent to creating FI_OTHER_PROVIDER.  I also don't like the way comp_list behaves differently from other attributes, such as prov_name.  E.g. can the app request specific utility components?  How does that even work when they layer over each other?
> 
> I've also thought about pushing the problem to the core providers.  A core provider can use the generalized utilities to support the same features as the utility providers.  This leaves us where we are today.
> 
> I can see a benefit of users NOT needing to know about the utility components.  But I also don't see an easy way to completely hide their existence.
> 
> - Sean
> _______________________________________________
> ofiwg mailing list
> ofiwg at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofiwg