[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?
Keith
More information about the ofiwg
mailing list