[ofiwg] presentation from today's WG meeting

Underwood, Keith D keith.d.underwood at intel.com
Thu Apr 24 04:17:21 PDT 2014

> On Apr 24, 2014, at 6:16 AM, "Jeff Squyres (jsquyres)" <jsquyres at cisco.com> wrote:
>> On Apr 22, 2014, at 11:22 AM, Doug Ledford <dledford at redhat.com> wrote:
>> The other thing I want to request is that we plan for making this
>> library function either as a single threaded, main loop driven
>> application (which the code you've posted seems well suited for), or as
>> a threaded, event driven library (which there currently is no definition
>> for).  I'm fine if we say that the application must do one or the other
>> and not both, or if we have strict rules about how the methods can be
>> mixed, but in the event model I specifically imagine that A) the library
>> will have its own threads that do certain tasks and B) the library will
>> allow the application to register callbacks and instead of the
>> application polling the library for received data or send completions,
>> we can use those callbacks to notify the application instead (and in
>> this case, let's say the application registers a callback for send
>> completions, but not for recv completions, then the send path in the
>> library would use the callback method while the application would be
>> responsible for polling for recv completions).  Exactly which options
>> being enabled result in library generated threads would have to be
>> explicitly spelled out so that applications that don't want the library
>> to generate threads on its own can avoid making it do so.
> This is a great idea in principle (it's pretty much the "active messages" idea), but I'll warn that there are many, many dragons here.
> The tarpit that this idea leads to is defining exactly what behavior is allowed in a callback.
> Case in point: the MPI Forum has argued *for years* (literally) about how to enable callbacks in receives.  It's never happened because of the zillions of corner cases that come up; trying to define them all is a losing 

Don't forget the other dragons:  what are the progress guarantees? What are the performance expectations?


More information about the ofiwg mailing list