This test should be fixed by the latest commits.

See #1945

Signed-off-by: Huiwei Lu <huiweilu@mcs.anl.gov>

Improves the anysource test by doing more error checking to provide
better output.

Signed-off-by: Huiwei Lu <huiweilu@mcs.anl.gov>

We will now return a request handle from MPI_IRECV even if there is a
failure. The reason for this is because the ULFM spec says that even if
the function returns MPIX_ERR_PROC_FAILED_PENDING, it still should
provide a valid request that can be completed later.

This doesn't cause a problem for other situations because the value of
the request is undefined in that scenario so it's fine for it to be
garbage.

Signed-off-by: Huiwei Lu <huiweilu@mcs.anl.gov>

Before calling the progress engine, make sure none of the operations
should return an error for MPIX_ERR_PROC_FAILED_PENDING. They would
cause the progress engine to hang (potentially) so we can't enter it.
Instead, mark the appropriate error codes and return immediately.

Signed-off-by: Huiwei Lu <huiweilu@mcs.anl.gov>

Anysource requests involving a communicator that isn't collectively
active should be appended to the posted queue the error class should be
marked as MPIX_ERR_PROC_FAILED_PENDING. The operation can still be
completed later.

Signed-off-by: Huiwei Lu <huiweilu@mcs.anl.gov>

This function will check to see if a request can be completed if it
involves MPI_ANY_SOURCE. An any source request cannot be completed if
the communicator is not collectively active.

Signed-off-by: Huiwei Lu <huiweilu@mcs.anl.gov>

There is a complete overhaul of this file on the way, but in the meantime
we raise these limits to prevent deadlock in MPI_Finalize with process
count >= 12.

No reviewer.

The F77/90 test is marked as xfail for a bug at
https://trac.mpich.org/projects/mpich/ticket/1877



Signed-off-by: Wesley Bland <wbland@anl.gov>

Signed-off-by: Pavan Balaji <balaji@anl.gov>

Signed-off-by: Pavan Balaji <balaji@anl.gov>

These two functions will be included in MPI-3.1 and hence are implemented as MPIX.
See more about this MPI-Forum ticket at https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/349



Fixes #2134, #2136

Signed-off-by: Pavan Balaji <balaji@anl.gov>

Signed-off-by: Wesley Bland <wbland@anl.gov>

Some mpi tests such as bcast2 and bcast3 take 20mins to run all the
datatypes on tcp. Therefore, we also define a minimum version of the
datatype generator which only generates vector and indexed tests so that
such heavy tests can use the min version to shorten time.

We enable the full version by default, tests can turn to min version by
calling the corresponding init func before datatype loop.

In coll/bcast2, coll/bcast3 and pt2pt/pingpong tests, we change to min
version from the second datatype loop.

Signed-off-by: Wesley Bland <wbland@anl.gov>

0 count is not allowed in subarray. Please revert this change if it has
special reason to set count-1 in the datatype while loop.

Signed-off-by: Wesley Bland <wbland@anl.gov>

Each mpi test originally called the mtest datatype by using a hardcoded
count loop. Now we predefine a count loop and let the mpi tests call
this predefined loop instead of hardcoding. This change allows the mtest
routine to manage the size of generated datatypes in every mpi
test (i.e., to ensure that every mpi test reaches the large message
algorithms).

Signed-off-by: Wesley Bland <wbland@anl.gov>

Add hvector, hindexed, indexed_block, hindexed_block, struct,
subarray with order-c and subarray with order-fortran datatypes.

Signed-off-by: Wesley Bland <wbland@anl.gov>

Signed-off-by: Wesley Bland <wbland@anl.gov>

Signed-off-by: Wesley Bland <wbland@anl.gov>

This patch separates mtest datatype from file mtest.c and then rewrites
the whole structure for applying various test patterns and datatypes.

We separate mtest datatype funcs and test generators.
1. In mtest_datatype_gen.c, we generate test cases for both basic and
derived datatype.
2. In mtest_datatype.c, we define the MTestDatatype creator,
init/free/check functions for each derived datatype in order to reuse in
multiple test cases generated by 1.

About test case definition:
1. For every basic datatype, we only define one test case using
the same type for both send and receive buffers.
2. For every derived datatype, we test ddt send buffer and receive
buffer separately, each with contig buffer on the other side. We define
following four different ddt structures for each test:
	a.large block length
	b.large count
	c.large block length and large stride
	d.large count and large stride

Signed-off-by: Wesley Bland <wbland@anl.gov>

Set the maximum number of origin events to the returned limit from
PtlNIInit. Rportals uses the value to prevent exhausting the local
EQ and causing a flowcontrol event.

No reviewer.

Kenneth Raffenetti authored Nov 04, 2014 and Pavan Balaji committed Nov 05, 2014

The large send handler incorrectly assumed event ordering from portals.
This could lead to a request being freed while pending events would
still attempt to access it, causing a segfault or incorrect handler to
execute.

Signed-off-by: Pavan Balaji <balaji@anl.gov>

Kenneth Raffenetti authored Oct 28, 2014 and Pavan Balaji committed Nov 05, 2014

In large message cases, when multiple get operations are issued, the
data may arrive out-of-order back at the initiator. A counter is required
to ensure all operations have completed. In the temporary buffer case, we
simply wait for all the data to arrive, and unpack in one operation.

Signed-off-by: Pavan Balaji <balaji@anl.gov>

Kenneth Raffenetti authored Oct 23, 2014 and Pavan Balaji committed Nov 05, 2014

This is useful test case for netmods that use packing and/or break
large messages into smaller chunks.

Signed-off-by: Pavan Balaji <balaji@anl.gov>

Kenneth Raffenetti authored Oct 24, 2014 and Pavan Balaji committed Nov 05, 2014

Move some duplicate code for posting multiple get operations into a
dedicated helper function.

Signed-off-by: Pavan Balaji <balaji@anl.gov>

Kenneth Raffenetti authored Oct 23, 2014 and Pavan Balaji committed Nov 05, 2014

Large messages (either larger than max_msg_size or > MPID_IOV_LIMIT), will
be packed into a temporary buffer. These need to be optimized.

Signed-off-by: Pavan Balaji <balaji@anl.gov>

Kenneth Raffenetti authored Oct 10, 2014 and Pavan Balaji committed Nov 05, 2014

If a message is larger than the max_msg_size limit, issue multiple MEs
for the remainder of the message. Completion events for the intermediate
operations will be ignored. Only the final operation will trigger the
event handler to tell MPI that communication is complete.

Signed-off-by: Pavan Balaji <balaji@anl.gov>

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: Xin Zhao <xinzhao3@illinois.edu>

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: Xin Zhao <xinzhao3@illinois.edu>

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: Xin Zhao <xinzhao3@illinois.edu>

It was commented out due to a cce/8.3.0 bug. Since the bug is fixed in cce/8.3.2,
we can safely uncomment the code.

No reviewer

An EQ for origin events is useful for rate-limiting operations so that
a process does not locally trigger a flow control event on its portal.
We will implement the rate-limiting logic in the rportals layer.

Signed-off-by: Antonio J. Pena <apenya@mcs.anl.gov>

Rather than use an EQ limit that may be lower than the system default,
just create our EQ using the returned maximum from PtlNIInit.

Signed-off-by: Antonio J. Pena <apenya@mcs.anl.gov>

The new enum name is more descriptive to describle an MPIR_MPI_State_t
that says MPICH is in initialization but not completely finished.

Signed-off-by: Pavan Balaji <balaji@anl.gov>

Implements MPI-Forum ticket 357 (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/357

)

The ticket will be included in MPI-3.1, which adds thread-safety to MPI_INITIALIZED,
MPI_FINALIZED, MPI_QUERY_THREAD, MPI_IS_THREAD_MAIN, MPI_GET_VERSION and
MPI_GET_LIBRARY_VERSION.

In MPICH, we make MPIR_Process.mpich_state atomic. After MPI is fully initialized, i.e.,
in POST_INIT state, MPI_QUERY_THREAD, MPI_IS_THREAD_MAIN are inherently thread-safe.

Fixes #2137

Signed-off-by: Pavan Balaji <balaji@anl.gov>

Also remove numbering for each enum, which is not necessary and is
hard to maintain.

Signed-off-by: Pavan Balaji <balaji@anl.gov>

Add some original RMA PVARs back to the new
RMA infrastructure, including timing of packet
handlers, op allocation and setting, window
creation, etc.

Signed-off-by: Pavan Balaji <balaji@anl.gov>

Names of static functions and types need not to have
namespacing. Here we remove prefix MPIDI_CH3I_ for
those functions and types.

Signed-off-by: Pavan Balaji <balaji@anl.gov>

We made a huge change to RMA infrastructure and
a lot of old code can be droped, including separate
handlers for lock-op-unlock, ACCUM_IMMED specific
code, O(p) data structure code, code of lazy issuing,
etc.

Signed-off-by: Pavan Balaji <balaji@anl.gov>

1. Piggyback LOCK request with first IMMED operation.

When we see an IMMED operation, we can always piggyback
LOCK request with that operation to reduce one sync
message of single LOCK request. When packet header of
that operation is received on target, we will try to
acquire the lock and perform that operation. The target
either piggybacks LOCK_GRANTED message with the response
packet (if available), or sends a single LOCK_GRANTED
message back to origin.

2. Rewrite code of manage lock queue.

When the lock request cannot be satisfied on target,
we need to buffer that lock request on target. All we
need to do is enqueuing the packet header, which contains
all information we need after lock is granted. When
the current lock is released, the runtime will goes
over the lock queue and grant the lock to the next
available request. After lock is granted, the runtime
just trigger the packet handler for the second time.

3. Release lock on target side if piggybacking with UNLOCK.

If there are active-message operations to be issued,
we piggyback a UNLOCK flag with the last operation.
When the target recieves it, it will release the current
lock and grant the lock to the next process.

Signed-off-by: Pavan Balaji <balaji@anl.gov>

We must make the initial value of enum to zero because some places
check number of packet types by checking ending type value.

Signed-off-by: Pavan Balaji <balaji@anl.gov>