[ofiwg] utility component/providers

Hefty, Sean sean.hefty at intel.com
Wed Mar 8 21:45:37 PST 2017

Based on discussions in the ofiwg, I'm most of the way down the path of treating utility providers as 'shadow' providers.  They're mostly invisible to an app.
EXCEPT, I shouldn't have saved updating fi_fabric() for last...  We need some way to go from:

struct fi_fabric_attr {
	struct fid_fabric	*fabric;
	char			*name;
	char			*prov_name;
	uint32_t		prov_version;
	uint32_t		api_version;

to the correct provider.  The proposed behavior for utility/shadow providers is:

1. Are not affected by any filtering logic.
   They are always enabled with debugging turned on.

2. Have their getinfo calls invoked if prov_name is any core provider.
   If prov_name is a util provider, the call routes directly

3. Set prov_name to: core_name:ofi-xxx

4. Will only layer over core providers.
   An internal flag is used to prevent nesting

5. Report themselves directly for FI_PROV_ATTR_ONLY getinfo calls.
   For debug purposes

From the viewpoint of an app, this means that the returned prov_name may differ from the getinfo input.  The man pages don't specify the behavior on this.  If this isn't acceptable, then we either require the app to update to 1.5 to use a util provider or keep the existing behavior with util providers exposed as separate providers.  (I don't like the idea of encoding the provider in the fabric name).  So, which option sucks less?

- Sean

More information about the ofiwg mailing list