[ofiwg] Provider capabilities query

[Hefty, Sean]

I think the ideal answer is that the provider should implement the call.  The implementation may not be optimized, but it should be usable.

The framework can help here by providing implementations where call fi_xxyy() calls fi_*msg.

- Sean


> Hi, All,
> 
> I'd like to discuss some issue with the multiple providers usage.
> Initially I faced the issue with the Mpich OFI netmod. We've added
> extended API set in the netmod that utilizes fi_tsenddata. However, as it
> turns out this particular function is not implemented, e.g. in the PSM
> provider. Which means in this case at the netmod level I should fallback
> to the legacy API based on fi_tsend. The question is now:
> 
> How can an OFI client (the netmod in this particular example) query if
> such capabilities are enabled in the provider? It seems that right now I
> have to open an endpoint, try to call fi_tsenddata (maybe to myself) and
> check if it returns ok. Which is neither convenient nor correct in
> general.
> 
> 
> 
> The only possibility left is to choose the API set based on the provider
> name (and information is to be taken from the provider man pages). This
> approach looks clumsy to me. On the one hand the client code that utilizes
> OFI is provider agnostic (which is the strength of the generic API) but on
> the other hand I have to plug in the explicit provider names.
> 
> 
> 
> At the same time, there should be no NULL pointers in providers "op"
> structure. For example, the unimplemented fi_tsenddata in the PSM provider
> is set to some internal predefined stub - fi_tagged_no_senddata. If, eg,
> those stubs were part of OFI user interface I could use them to check the
> pointer explicitly and thus understand if the provider implements the
> necessary functionality. But still, I need an initialized tagged ep for
> this. However, ideally I'd like to make a decision based on fi_info
> solely, so that I wouldn't do extra resource management.
> 
> 
> 
> So, what is the right way to solve this issue with the current OFI APIs?
> Or do we need another update to the API for this?
> 
> 
> 
> --
> 
> BR,
> 
> Valentin Petrov
> 
> 
> 
> 
> --------------------------------------------------------------------
> Closed Joint Stock Company Intel A/O
> Registered legal address: Krylatsky Hills Business Park,
> 17 Krylatskaya Str., Bldg 4, Moscow 121614,
> Russian Federation
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.