[ofiwg] spreadsheet form this morning's call

[Howard Pritchard]

Hi Sean,

2015-04-21 15:29 GMT-06:00 Hefty, Sean <sean.hefty at intel.com>:

> Unless everyone agrees with what randomness I come up with in the wee
> hours of the night, we need to know:
>
> Are the priorities correct for the targeted apps?
>

Speaking for the MPI crew, I'd agree with the high priority for tag
matching for RDM providers
that don't support that in hardware.

I would say having the framework handle the case of a provider asserting
the FI_LOCAL_MR mode
bit would be high as well.  Having to do memory registration caching in the
MPI implementation can
be a lot of work - esp. if the MPI implementation doesn't have access to
something like ummunotify <http://wn.net/Articles/343351/>.
So being able to hide memory registration issues within the framework would
be nice.

Being able to support FI_MR_SCALABLE within the framework would be great,
although its not
clear to me that this would be easy to do with providers who's hw doesn't
already support this
feature, modulo comments below.

FI MULTI_RECV would be of interest to the MPI crew as well -as you've
indicated with green.



> What requirements are needed from the underlying provider to provide each
> feature set?
>

need to think about this one, particularly for supporting FI_MR_SCALABLE in
the framework in
away that's at least partially performant.


> Are the different levels defined for each endpoint useful?
>

yes


>
> In addition to simplifying things for the app developers, this identifies
> which features the framework should implement as helper functionality.  So
> we don't implement features that really aren't needed, or have the
> framework implement features that will negatively impact the performance of
> using a given provider.
>
> - Sean
>
> _______________________________________________
> ofiwg mailing list
> ofiwg at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofiwg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofiwg/attachments/20150421/2891deac/attachment.html>