1. 07 Nov, 2014 5 commits
  2. 06 Nov, 2014 13 commits
  3. 05 Nov, 2014 19 commits
  4. 04 Nov, 2014 3 commits
    • Min Si's avatar
      Add req RMA op tests checking local completion. · db61d8d8
      Min Si authored
      Rput/accumulate + wait guarantees local completion, which means we can
      modify local buffer after wait is finished. These two tests check the local
      completion of Rput and Raccumulate by modifying local buffer after wait
      and then checking remote data. We expect the remote data should be equal
      to the local data before modifying.
      Signed-off-by: default avatarXin Zhao <xinzhao3@illinois.edu>
    • Min Si's avatar
      Bug-fix: trigger OnFinal at end when receiving multiple segments. · ea444c34
      Min Si authored
      There are two request handlers used when receiving data:
      (1) OnDataAvail, which is triggered when data is arrived;
      (2) OnFinal, which is triggered when receiving data is finished;
      In progress engine, only OnDataAvail is triggered when a request is
      completed. The upper ch3 layer should change OnDataAvail to OnFinal when
      the coming receiving data will complete the request.
      However, in the original implementation, when receiving multiple
      segments for a large receive data, the OnDataAvail was reset to 0
      at the last segment hence the final action was lost. This patch fixed
      this bug.
      In RMA target put/acc/gacc packet handlers, OnDataAvail was reset to
      OnFinal function if OnDataAvail is 0 due to this bug. This patch also
      rewrites this part so that packet handlers only sets proper OnFinal
      handler at beginning and let the receiving data function change
      OnDataAvail to OnFinal at the last segment.
      Signed-off-by: default avatarXin Zhao <xinzhao3@illinois.edu>
    • Min Si's avatar
      Implement true request-based RMA operations. · 3e005f03
      Min Si authored
      There are two requests associated with each request-based
      operation: one normal internal request (req) and one newly
      added user request (ureq). We return ureq to user when
      request-based op call returns.
      The ureq is initialized with completion counter (CC) to 1
      and ref count to 2 (one is referenced by CH3 and another
      is referenced by user). If the corresponding op can be
      finished immediately in CH3, the runtime will complete ureq
      in CH3, and let user's MPI_Wait/Test to destroy ureq. If
      corresponding op cannot be finished immediately, we will
      first increment ref count to 3 (because now there are
      three places needed to reference ureq: user, CH3,
      progress engine). Progress engine will complete ureq when
      op is completed, then CH3 will release its reference during
      garbage collection, finally user's MPI_Wait/Test will
      destroy ureq.
      The ureq can be completed in following three ways:
      1. If op is issued and completed immediately in CH3
      (req is NULL), we just complete ureq before free op.
      2. If op is issued but not completed, we remember the ureq
      handler in req and specify OnDataAvail / OnFinal handlers
      in req to a newly added request handler, which will complete
      user reqeust. The handler is triggered at three places:
         2-a. when progress engine completes a put/acc req;
         2-b. when get/getacc handler completes a get/getacc req;
         2-c. when progress engine completes a get/getacc req;
      3. If op is not issued (i.e., wait for lock granted), the 2nd
      way will be eventually performed when such op is issued by
      progress engine.
      Signed-off-by: default avatarXin Zhao <xinzhao3@illinois.edu>