1. 30 May, 2015 3 commits
    • Xin Zhao's avatar
      Add extended packet header in CH3 layer used by RMA messages · 25e40e43
      Xin Zhao authored
      
      
      Here we added extended packet header in CH3 layer used to
      transmit attributes that are only needed in RMA and are not
      needed in two-sided communication. The key implementation
      details are listed as follows:
      
      Origin side:
      
      (1) The extended packet header is stored in the request, and
      the request is passed to the issuing function (iSendv() or
      sendNoncontig_fn()) in the lower layer. The issuing function
      checks if the extended packet header exists in the request,
      if so, it will issue that header. (The modifications in lower
      layer are in the next commit.)
      
      (2) There is a fast path used when (origin data is contiguous &&
      target data is predefined && extended packet header is not used).
      In such case, we do not need to create a request beforehand
      but can use iStartMsgv() issuing function which try to issue
      the entire message as soon as possible.
      
      Target side:
      
      (1) There are two req handler being used when extended packet header
      is used or target datatype is derived. The first req handler is
      triggered when extended packet header / target datatype info is
      arrived, and the second req handler is triggered when actual data
      is arrived.
      
      (2) When target side receives a stream unit which is piggybacked with
      LOCK, it will drop the stream_offset in extended packet header, since
      the stream unit must be the first one and stream_offset must be 0.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
      25e40e43
    • Xin Zhao's avatar
      Revert "Move 'stream_offset' out of RMA packet struct." · 6f62c424
      Xin Zhao authored
      This reverts commit 19f29078
      
      .
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
      6f62c424
    • Xin Zhao's avatar
      Modify comments about piggybacking LOCK with op. · caeb3b3a
      Xin Zhao authored
      
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
      caeb3b3a
  2. 20 Apr, 2015 1 commit
    • Xin Zhao's avatar
      Move 'stream_offset' out of RMA packet struct. · 19f29078
      Xin Zhao authored
      
      
      'stream_offset' is used to specify the starting position
      (on target window) of the current streaming unit in ACC-like
      operations. It is originally put in the RMA packet struct,
      which potentially increases the size of CH3 packet size.
      
      In this patch, we move 'stream_offset' out of the RMA
      packet as follows: 1. when target data is basic datatype,
      we use 'stream_offset' and the starting address for the entire
      operation to calculate the starting address for current
      streaming unit, and rewrite 'addr' in RMA packet with that
      value; 2. when target data is derived datatype, we cannot do
      the same thing as basic datatype because the target needs to
      know both the starting address for the entire operation and
      the starting address for the current streaming unit. Therefore,
      we send 'stream_offset' separately to the target side.
      Signed-off-by: default avatarMin Si <msi@il.is.s.u-tokyo.ac.jp>
      Signed-off-by: default avatarAntonio J. Pena <apenya@mcs.anl.gov>
      19f29078
  3. 04 Mar, 2015 10 commits
    • Xin Zhao's avatar
      98c76f78
    • Xin Zhao's avatar
      Allocate buffer with stream size for ACC/GACC data piggybacked with LOCK. · 002ce8c8
      Xin Zhao authored
      
      
      For queued ACC/GACC data piggybacked with LOCK, we do not
      need to allocate the buffer for the entire operation, but
      only need to allocate a buffer with stream unit size. This
      patch fixes this issue.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
      002ce8c8
    • Xin Zhao's avatar
      Modify do_accumulate_op to allow for packed basic type data as input. · 0d5146ba
      Xin Zhao authored
      
      
      Originally, do_accumulate_op() is used to perform the ACC
      computation on target between data from origin side and
      data on the target window. It requires that the target side
      must first unpack the received origin data into the same data
      layout as the target data before calling this function, which
      may consume potentially large of memory.
      
      This patch fixes do_accumulate_op() function in the following
      aspects:
      
      (1) It requires that the origin data passed to the function
      must be "in a packed manner", which means it looks as if all
      basic type elements in the origin data is placed one by one.
      Note that the origin data is not necessarily contiguous, since
      we may use non-contiguous basic type. If the basic type
      is contiguous, then the origin data must be contiguous.
      
      (2) It adds a new function argument, stream_offset, which
      specifies a starting location in the target data. This allows
      the origin data to work with partial of target data with stream
      size.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
      0d5146ba
    • Xin Zhao's avatar
      Add counter in op struct to remember number of stream units issued. · c986b927
      Xin Zhao authored
      
      
      Add a counter in op struct to remember number of stream units
      that have already been issued. For example, when the first stream
      unit piggybacked with LOCK is issued out, we temporarily stop
      issuing the following units. After the origin receives the ACK
      from the target, it can continue to issue the following units.
      This counter helps avoid issuing the first unit again.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
      c986b927
    • Xin Zhao's avatar
      Use a request array in RMA operation. · ab8386e7
      Xin Zhao authored
      
      
      Because we may cut one RMA operation into multiple packets,
      and each packet needs a request object to track the completion,
      here we use a request array instead of single request in
      RMA operation structure.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
      ab8386e7
    • Xin Zhao's avatar
      Code refactoring: setting ureq after issuing op in a function. · a36fd9dd
      Xin Zhao authored
      
      
      After (1) issuing an op (no LOCK flag), or (2) issuing an op
      (with LOCK flag) and receiving an ACK that LOCK is granted or
      queued, we should set the user request (ureq) to be completed.
      This patch wraps up the work of setting ureq into a function,
      and call that function after (1) and (2) happens.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
      a36fd9dd
    • Xin Zhao's avatar
      Modify location of setting next_op_to_issue and sync_flag to NONE · fd92b7bc
      Xin Zhao authored
      
      
      After we issue an op, we set the next_op_to_issue to the next op,
      and if next op is NULL, we set sync_flag to NONE. When we receive
      the lock ACK saying that lock request is discarded, we set the
      next_op_to_issue back to the current op, we reset the sync_flag
      from NONE to corresponding flag, since we need to re-transmit the
      current op.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
      fd92b7bc
    • Xin Zhao's avatar
      Change name from data_size to buf_size. · 45cdb282
      Xin Zhao authored
      
      
      When the lock is not satisfied, we queue up
      the lock request and op data in a lock entry
      queue. In the struct of lock entry, we use 'data_size'
      to remember the size of buffer for storing the
      data. Since the size of buffer is not type_size*count
      but might be type_extent*extent, here we change
      its name from 'data_size' to 'buf_size'.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
      45cdb282
    • Xin Zhao's avatar
      Bug-fix: make RMA work correctly with pair basic type. · ce8bc310
      Xin Zhao authored
      
      
      The original implementation of RMA does not consider pair basic
      types (e.g. MPI_FLOAT_INT, MPI_DOUBLE_INT). It only
      works correctly with builtin datatypes (e.g. MPI_INT, MPI_FLOAT).
      This patch makes the RMA work correctly with pair basic types.
      
      The bug is that: (1) when performing the ACC computation, the original
      implementation uses 'eltype' in the datatype structure, which is set
      when all basic elements in this datatype have the same builtin
      datatype. When basic elements have different builtin datatypes, like
      pair datatypes, the 'eltype' is set to MPI_DATATYPE_NULL. This makes
      the ACC computation be unable to work with pair types; (2) for all
      basic type of data, the original implementation assumes that
      they are all contiguous and issues them in an unpacked manner
      with length of data size (count*type_size). This is incorrect for
      pair datatypes, because most pair datatypes are non-contiguous
      (type_extent != type_size).
      
      In the previous patch, we already made 'eltype' to store basic
      type instead of builtin type. In this patch, we fixed this
      bug by (1) modify ACC computation to treat 'eltype' as basic
      type; (2) For non-contiguous basic type data, we use the noncontig
      API so that it will be issued in a packed manner.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
      ce8bc310
    • Xin Zhao's avatar
      Store window basic attributes into a struct on window. · 9404e953
      Xin Zhao authored
      
      
      In this patch, we gather window basic attributes of other
      processes (base_addr, size, disp_unit, win_handle) using a
      struct called "basic_info_table". By doing this, we can use
      one contiguous memory region to store them.
      Signed-off-by: Pavan Balaji's avatarPavan Balaji <balaji@anl.gov>
      9404e953
  4. 03 Mar, 2015 1 commit
  5. 13 Feb, 2015 4 commits
    • 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,
      GET, FOP, CAS, GACC_RESP, GET_RESP, FOP_RESP, CAS_RESP),
      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>
      80a71e11
    • 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>
      1b30ab19
    • 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>
      de9d0f21
    • 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>
      81e2b274
  6. 16 Dec, 2014 17 commits
  7. 13 Nov, 2014 3 commits
  8. 03 Nov, 2014 1 commit