<div dir="ltr">Some of the requirements for FT include:<div>- precise error code reporting on failures.  deadlock never occurs due to remote process failure.</div><div>- containment of side effects of endpoint failures, especially no byzantine behavior.</div><div>- easy to deregister failed endpoints.</div><div>- easy to register new endpoints on the fly.  (think MPI_Comm_spawn_multiple here)</div><div><br></div><div>Thanks,</div><div><br></div><div>Jeff</div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 8, 2015 at 10:28 AM, Sur, Sayantan <span dir="ltr"><<a href="mailto:sayantan.sur@intel.com" target="_blank">sayantan.sur@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
><br>
>What would be more helpful would be to have OFI provide a well-specified<br>
>mechanism for reporting communication failures that it can’t<br>
>automatically resolve. Some sort of error reporting from OFI calls to say<br>
>that a specific send failed would be nice. From that error code, we can<br>
>infer which target failed since OFI doesn’t have any collectives which<br>
>would make this more difficult.<br>
<br>
<br>
</span>Errors should be reported to the CQ readerr. That’s what you want, right?<br>
<br>
Thanks,<br>
Sayantan.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
><br>
>Thanks,<br>
>Wesley<br>
><br>
><br>
><br>
>On 9/8/15, 11:57 AM, "<a href="mailto:ofiwg-bounces@lists.openfabrics.org">ofiwg-bounces@lists.openfabrics.org</a> on behalf of<br>
>Hefty, Sean" <<a href="mailto:ofiwg-bounces@lists.openfabrics.org">ofiwg-bounces@lists.openfabrics.org</a> on behalf of<br>
><a href="mailto:sean.hefty@intel.com">sean.hefty@intel.com</a>> wrote:<br>
><br>
>>> What's the state of fault-tolerance in OFI?  Would it be prudent for<br>
>>> someone to write OFI code that aspired to survive process failures?<br>
>>>Are<br>
>>> any implementations known to support this robustly right now?<br>
>><br>
>>This would be provider specific.  I'm not aware of anything that's coded<br>
>>to handle failures.<br>
>><br>
>>Having an example of this over libfabric would be great, though I'm not<br>
>>sure who's going to volunteer to write this.<br>
>><br>
>>It's not clear to me how fault tolerance relates to a networking API.<br>
>>For example, what specific lower-level features does an app need to make<br>
>>this happen?  Are their restrictions that providers need to report to<br>
>>apps regarding their level of support?  Is this something that even<br>
>>belongs to this level of API?<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" rel="noreferrer" target="_blank">http://lists.openfabrics.org/mailman/listinfo/ofiwg</a><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" rel="noreferrer" target="_blank">http://lists.openfabrics.org/mailman/listinfo/ofiwg</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>
</div></div></div>