<div dir="ltr"><div class="gmail_extra">Hi Sean,</div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-21 15:29 GMT-06:00 Hefty, Sean <span dir="ltr"><<a href="mailto:sean.hefty@intel.com" target="_blank">sean.hefty@intel.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Unless everyone agrees with what randomness I come up with in the wee hours of the night, we need to know:<br>
<br>
Are the priorities correct for the targeted apps?<br></blockquote><div><br></div><div>Speaking for the MPI crew, I'd agree with the high priority for tag matching for RDM providers</div><div>that don't support that in hardware.</div><div><br></div><div>I would say having the framework handle the case of a provider asserting the FI_LOCAL_MR mode</div><div>bit would be high as well.  Having to do memory registration caching in the MPI implementation can</div><div>be a lot of work - esp. if the MPI implementation doesn't have access to something like <a href="http://wn.net/Articles/343351/">ummunotify</a>.</div><div>So being able to hide memory registration issues within the framework would be nice.</div><div><br></div><div>Being able to support FI_MR_SCALABLE within the framework would be great, although its not</div><div>clear to me that this would be easy to do with providers who's hw doesn't already support this</div><div>feature, modulo comments below.</div><div><br></div><div>FI MULTI_RECV would be of interest to the MPI crew as well -as you've indicated with green.</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What requirements are needed from the underlying provider to provide each feature set?<br></blockquote><div><br></div><div>need to think about this one, particularly for supporting FI_MR_SCALABLE in the framework in </div><div>away that's at least partially performant. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Are the different levels defined for each endpoint useful?<br></blockquote><div><br></div><div>yes</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Sean<br>
</font></span><br>_______________________________________________<br>
ofiwg mailing list<br>
<a href="mailto:ofiwg@lists.openfabrics.org">ofiwg@lists.openfabrics.org</a><br>
<a href="http://lists.openfabrics.org/mailman/listinfo/ofiwg" target="_blank">http://lists.openfabrics.org/mailman/listinfo/ofiwg</a><br>
<br></blockquote></div><br></div></div>