1. 30 May, 2015 6 commits
  2. 27 May, 2015 2 commits
  3. 26 May, 2015 1 commit
  4. 20 May, 2015 3 commits
  5. 13 May, 2015 2 commits
  6. 10 May, 2015 2 commits
  7. 29 Apr, 2015 1 commit
  8. 27 Apr, 2015 5 commits
    • Valentin Petrov's avatar
      OFI: Bug fix for RTS/CTS/DATA protocol. · 2069c15e
      Valentin Petrov authored
      MPID_nem_ofi_data_callback used to check sreq->cc in order to track progress of
      the RTS/CTS/DATA protocol. The was an implicit assumption that fi_tsend with RTS
      completes first. However this would cause a hang if fi_trecv completed earlier.
      The fix is: don't rely on the cc but rather check the tag bits explicitly.
      Note, the RTS/CTS/DATA bits are no longer accumulated (i.e., no more
      "wc->tag | CTS/DATA").
      Signed-off-by: default avatarCharles J Archer <charles.j.archer@intel.com>
    • Valentin Petrov's avatar
      OFI: MPIR_Barrier_impl should not be called from MPID_nem_ofi_finalize. · 34e57aa8
      Valentin Petrov authored
      It uses nemesis shared memory which is already cleaned up at this stage.
      However, w/o any synchronization a hang in the close protocol is possible
      since rts/cts/data messages may be on the fly. This change fixes the issue.
      Signed-off-by: default avatarCharles J Archer <charles.j.archer@intel.com>
    • Valentin Petrov's avatar
    • Valentin Petrov's avatar
    • Valentin Petrov's avatar
      OFI: Add support for large tags using immediate data and OFI tag layouts · ec920e5f
      Valentin Petrov authored
      This patch modifies the OFI netmod to support large tag layouts, while preserving the old
      tag layout.  OFI defines a 64 bit tag, but also provides for a 64 bit tag and immediate data.
      In some OFI providers, we may want to select different tag layouts.  This patch currently
      does not query for the proper tag layout or attempt to make a choice of the optimal layout,
      it provides macro/templatized support for different tag formats.  Additional selection
      criteria will be added in subsequent patches.
        * Tag layout is moved to a separate file.
          Added init_sendtag_M2, init_recvtag_M2 (M2 stands for MODE #2, i.e. the mode
          that uses fi_tsenddata and does not pack source into tag).
        * Created a template file for ofi_tagged.c
          Moved do_isend into template file which is included twice into ofi_tagged.c thus providing for the two
          versions of do_isend and do_isend_2 corresponding to the two API sets.
        * All send functions are available in two versions.
          Added macro that declares a function for the two API sets. The first set has the namings inherited from
          the previous netmod version. The functions of the second API set have the "_2" suffix.
        * Recv_posted, anysource_posted, recv_callback, ofi_probe  are templatized.
        * ofi_tag_to_vc renamed ofi_wc_to_vc
          Note, for the API_SET_2 the pgid is stored in the imm data while
          psource and port will be packed the same way as in API_SET_1.
        * Adds api_set member in gl_data struct.  Initialize routines based on api_set
        * Added RCD (RtsCtsData) protocol identifiers
        * Added support for OFI MEM_TAG_FORMAT
        * PGID placement modified
      Signed-off-by: default avatarCharles J Archer <charles.j.archer@intel.com>
  9. 24 Apr, 2015 1 commit
  10. 22 Apr, 2015 3 commits
    • Pavan Balaji's avatar
      Fix arbitrary poll count before yielding. · abb56764
      Pavan Balaji authored
      Instead of polling for an arbitrarily decided number of times in the
      progress engine before yielding, we now moved the yielding
      intelligence to the threading layer.  The threading layer can keep
      track of other threads that are waiting to enter the critical section
      and only yield if another thread is waiting.  In this way, if no
      thread is waiting to get the lock, the main thread never yields.  At
      the same time, if another thread is waiting to get a lock, there is no
      delay in yielding.
      This change, however, introduces possible deadlocks. If a thread enters
      MPIDI_CH3I_progress with is_blocking unset, it may set the
      MPIDI_CH3I_progress_blocked flag and then will yield the critical section.
      Another thread may enter with is_blocking set, find the flag
      MPIDI_CH3I_progress_blocked set, and block in the conditional variable.
      The first thread will wake up and leave the progress engine without
      emitting any signal to wake up the second thread which may sleep forever.
      A simple fix is to yield the critical section only if the current thread
      entered the progress engine with is_blocking set.
      Signed-off-by: default avatarHalim Amer <aamer@anl.gov>
    • Pavan Balaji's avatar
      Cleanup threaded progress. · f385680e
      Pavan Balaji authored
      The nemesis progress engine was written in a way so that if one thread
      is inside a progress engine, other threads cannot enter the receive
      progress.  They can enter the send progress in some cases.  There
      doesn't seem to be a good reason for this behavior.  This patch
      combines this so threads would simply return for nonblocking
      operations and wait for a signal before entering the progress engine
      for blocking operations.
      Signed-off-by: default avatarHalim Amer <aamer@anl.gov>
    • Kenneth Raffenetti's avatar
      mxm: fix anysource_matched · 1be5fc49
      Kenneth Raffenetti authored
      The return value of anysource_matched should be the actual result
      of the cancel operation. If the result is uncancelable, i.e. already
      matched, then CH3 will let the netmod message win and move on to the
      other requests in the queue. When the completion for the unsuccessfully
      canceled message comes in, we process it like normal.
      Reviewed-by: default avatarIgor Ivanov <Igor.Ivanov@itseez.com>
      Signed-off-by: default avatarAntonio J. Pena <apenya@mcs.anl.gov>
  11. 20 Apr, 2015 8 commits
  12. 17 Apr, 2015 3 commits
    • Halim Amer's avatar
      Revert "Applied the PPoPP patch" · cae26234
      Halim Amer authored
      This reverts commit 17e31e59.
    • Halim Amer's avatar
      Applied the PPoPP patch · 17e31e59
      Halim Amer authored
    • Kenneth Raffenetti's avatar
      portals4: fix anysource_matched · 73e32112
      Kenneth Raffenetti authored
      This fix, along with a pending patch to the Portal4 reference implementation,
      should make anysource_matched a more reliable operation for multithreaded apps. We
      were seeing a race condition where an ME would unlink successfully, but an
      event matching it would still arrive in the queue. CH3 can now reliably search
      the netmod queue for matched MPI_ANY_SOURCE requests.
      The reason that we no longer assert that an MPI_ANY_SOURCE request was removed
      from the CH3 queue is that FDP (find and dequeue posted) operations will remove
      the request from the queue, if it is known to be already matched by the netmod,
      even if it has not yet completed.
      Fixes #2199
      Signed-off-by: default avatarAntonio J. Pena <apenya@mcs.anl.gov>
  13. 15 Apr, 2015 1 commit
  14. 14 Apr, 2015 1 commit
  15. 10 Apr, 2015 1 commit
    • Kenneth Raffenetti's avatar
      portals4: tuning · daf29e33
      Kenneth Raffenetti authored
      Changes the value of various static limits in the Portals4 netmod, based
      on experimentation results and suggestions from collaborators.
      1. Bump most ni_limits from 32K to 64K. These limits relate closely to
         queue depth. We can reasonably expect to support a queue depth
         of 64K.
      2. Limit issued origin events to 500. This translates to sending ~250
         operations to Portals at a time, which over IB is roughly the
         saturation point. TODO: turn this into a CVAR.
      3. Limit per target issued operations to 50. This will give the target a
         better chance to process events without being overwhelmed by a single
         process. TODO: turn this into a CVAR, also.
      4. Allocate more buffer space for incoming control messages. Observed
         results, especially with larger messages, showed that more buffer space
         cuts down on flow-control events.
      Signed-off-by: default avatarAntonio J. Pena <apenya@mcs.anl.gov>