1. 01 Mar, 2015 4 commits
  2. 27 Feb, 2015 7 commits
  3. 26 Feb, 2015 7 commits
  4. 25 Feb, 2015 2 commits
  5. 24 Feb, 2015 1 commit
  6. 23 Feb, 2015 1 commit
  7. 19 Feb, 2015 1 commit
  8. 18 Feb, 2015 1 commit
  9. 13 Feb, 2015 16 commits
    • Wesley Bland's avatar
      Only process recv requests · be7c17b3
      Wesley Bland authored
      Requests that aren't for receive operations don't have anything in them,
      so trying to process them only generates valgrind warnings with
      potentially unsafe behavior.
      Signed-off-by: default avatarHuiwei Lu <huiweilu@mcs.anl.gov>
    • Wesley Bland's avatar
      Don't check for anysource if not recv · 3b04f6c0
      Wesley Bland authored
      The function to check whether an operation was an anysource receive was
      checking all request kinds, even if they weren't receives. This limits
      that check to only receives to avoid examining an uninitialized
      Signed-off-by: default avatarHuiwei Lu <huiweilu@mcs.anl.gov>
    • Sameh Sharkawi's avatar
      PAMID: Initial CUDA support · d9c15cf3
      Sameh Sharkawi authored
      This is an initial limited implementation for CUDA support. This is not
      performance optimized and only for testing.
      (ibm) D202477
      Signed-off-by: default avatarSu Huang <suhuang@us.ibm.com>
    • Xin Zhao's avatar
    • Xin Zhao's avatar
      Delete comments that no longer make sense. · 21126e9e
      Xin Zhao authored
      The comments are no longer significant for
      new RMA infrastructure.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Delete unnecessary code. · e3ccad1f
      Xin Zhao authored
      Here req->dev.user_count is used when receiving FOP/CAS response
      data on origin in PktHandler_FOPResp and PktHandler_CASResp. Since
      the count always be 1, we did not set rma_op->result_count, and
      we directly set req->dev.user_count to 1 in packet handlers.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Simplify code of issuing RMA packets. · e3fc7e70
      Xin Zhao authored
      When issuing RMA packets, we do not need to
      store target_win_handle in the request on
      origin side but only need to store source_win_handle.
      Because when the response data is back, we
      only needs to use source_win_handle on origin
      size. This patch simplifies the code in this way.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Remove source_win_handle from GET-like RMA packets. · 80a71e11
      Xin Zhao authored
      For GET-like RMA packets and response packets (GACC,
      originally we carry source_win_handle in packet struct
      in order to locate window handle on origin side in the
      packet handler of response packets. However, this is
      not necessary because source_win_handle can be stored
      in the request on the origin side. This patch delete
      source_win_handle from those packets to reduce the size
      of packet union.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
    • Xin Zhao's avatar
      Bug-fix: use do_accumulate_op function for ACC computation. · c8ecef8d
      Xin Zhao authored
      do_accumulate_op() does more comprehensive work on ACC
      computation than OP function. For example, MPI_REPLACE
      is not defined as predefined computation and therefore
      not handled by OP function, but it is safely handled
      in do_accumulate_op(). This patch replace OP function
      with do_accumulate_op() on target side.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Use memcpy for structure assignment. · 59afc29c
      Xin Zhao authored
      In this patch we replace "=" with memcpy function
      when assigning structure content to another struct.
      Using "=" in this case is not compatible for llvm
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Change argument of function finish_op_on_target. · 1b30ab19
      Xin Zhao authored
      In this patch, we replace one argument of function
      finish_op_on_target, "packet(op) type", with "has_response_data".
      Since finish_op_on_target does not care what specific
      packet(op) type it is processing on, but only cares
      about if the current op has response data (like GET/GACC),
      changing the argument in this way can simplify the
      code by avoiding acquiring packet(op) type everytime
      before calling finish_op_on_target.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Add asserts for RMA packet types. · 21479b00
      Xin Zhao authored
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Rewrite code of piggybacking IMMED data with RMA packets. · de9d0f21
      Xin Zhao authored
      Originally we add "immed_data" and "immed_len" areas to RMA packets,
      in order to piggyback small amount of data with packet header to
      reduce number of packets (Note that "immed_len" is necessary when
      the piggybacked data is not the entire data). However, those areas
      potentially increase the packet union size and worsen the two-sided
      communication. This patch fixes this issue.
      In this patch, we remove "immed_data" and "immed_len" from normal
      "MPIDI_CH3_Pkt_XXX_t" operation type (e.g. MPIDI_CH3_Pkt_put_t), and
      we introduce new "MPIDI_CH3_Pkt_XXX_immed_t" packt type for each
      operation (e.g. MPIDI_CH3_Pkt_put_immed_t).
      "MPIDI_CH3_Pkt_XXX_immed_t" is used when (1) both origin and target
      are basic datatypes, AND, (2) the data to be sent can be entirely fit
      into the header. By doing this, "MPIDI_CH3_Pkt_XXX_immed_t" needs
      "immed_data" area but can drop "immed_len" area. Also, since it only
      works with basic target datatype, it can drop "dataloop_size" area
      as well. All operations that do not satisfy (1) or (2) will use
      normal "MPIDI_CH3_Pkt_XXX_t" type.
      Originally we always piggyback FOP data into the packet header,
      which makes the packet size too large. In this patch we split the
      FOP operaton into IMMED packets and normal packets.
      Because CAS only work with 2 basic datatype and non-complex
      elements, the data amount is relatively small, we always piggyback
      the data with packet header and only use "MPIDI_CH3_Pkt_XXX_immed_t"
      packet type for CAS.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Code-refactoring for RMA operations routines. · 3a017faa
      Xin Zhao authored
      This patch just does code refactoring for RMA operation rountines
      to make the code structure clearer. This patch does not change any
      After code refactoring, in each operation routine, for non-SHM operations
      we do the work in the following order:
      (1) allocate a new op struct;
      (2) fill areas in op struct, except for packet struct in op struct;
      (3) initialize packet struct in op struct, fill areas in packet struct;
      (4) enqueue op to data structure on window.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
    • Xin Zhao's avatar
      Remove lock_type and origin_rank areas from RMA packet. · 81e2b274
      Xin Zhao authored
      Originally we added lock_type and origin_rank areas
      in RMA packet, in order to piggyback passive lock request
      with RMA operations. However, those areas potentially
      enlarged the packet union size, and actually they are
      not necessary and can be completetly avoided.
      "Lock_type" is used to remember what types of lock (shared or
      exclusive) the origin wants to acquire on the target. To remove
      it from RMA packet, we use flags (already exists in RMA packet)
      to remember such information.
      "Origin_rank" is used to remember which origin has sent lock
      request to the target, so that when the lock is granted to this
      origin later, the target can send ack to that origin. Actually
      the target does not need to store origin_rank but can only store
      origin_vc, which is known from progress engine on target side.
      Therefore, we can completely remove origin_rank from RMA packet.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>