diff --git a/doc/wiki/developer_guide.md b/doc/wiki/developer_guide.md index 89102ca9bbf..eb0df5c9d0b 100644 --- a/doc/wiki/developer_guide.md +++ b/doc/wiki/developer_guide.md @@ -257,69 +257,39 @@ Reference: * [src/mpid/ch4/src/mpidig_recvq.h](../../src/mpid/ch4/src/mpidig_recvq.h) * [src/mpid/ch4/src/mpidig_rma.h](../../src/mpid/ch4/src/mpidig_rma.h) * [src/mpid/ch4/src/mpidig_rma_callbacks.h](../../src/mpid/ch4/src/mpidig_rma_callbacks.h) -* [src/mpid/ch4/src/mpidig_rma_callbacks.h](../../src/mpid/ch4/src/mpidig_rma_callbacks.h) - -Active message APIs as of MPICH 3.4.2: -``` -/****************** Header and Data Movement APIs ******************/ - -/* blocking header send */ -int MPIDI_[NM|SHM]_am_send_hdr(int rank, MPIR_Comm * comm, int handler_id, - const void *am_hdr, MPI_Aint am_hdr_sz) - -/* nonblocking header + datatype send */ -int MPIDI_[NM|SHM]_am_isend(int rank, MPIR_Comm * comm, int handler_id, - const void *am_hdr, MPI_Aint am_hdr_sz, - const void *data, MPI_Aint count, - MPI_Datatype datatype, MPIR_Request * sreq) - -/* nonblocking headers + datatype send */ -int MPIDI_[NM|SHM]_am_isendv(int rank, MPIR_Comm * comm, int handler_id, - struct iovec *am_hdrs, size_t iov_len, - const void *data, MPI_Aint count, - MPI_Datatype datatype, MPIR_Request * sreq) - -/* blocking header send (callback safe) */ -int MPIDI_[NM|SHM]_am_send_hdr_reply(MPIR_Comm * comm, int src_rank, - int handler_id, const void *am_hdr, - MPI_Aint am_hdr_sz) - -/* nonblocking header + datatype send (callback safe) */ -int MPIDI_[NM|SHM]_am_isend_reply(MPIR_Comm * comm, int src_rank, int handler_id, - const void *am_hdr, MPI_Aint am_hdr_sz, - const void *data, MPI_Aint count, - MPI_Datatype datatype, MPIR_Request * sreq) - -/* CTS for pt2pt messages */ -int MPIDI_[NM|SHM]_am_recv(MPIR_Request * rreq) +* [src/mpid/ch4/ch4_api.txt](../../src/mpid/ch4/ch4_api.txt) + +Active message APIs are generated from `src/mpid/ch4/ch4_api.txt` and +kept in sync with the current device implementation (MPICH 5.0.0a1 at +the time of writing). The canonical list in that file is extensive, but +the most commonly used entry points are summarized below. Every variant +receives both source and destination VCI identifiers so that multi-VCI +configurations can steer traffic explicitly. + +* **Header/data transport**: `MPIDI_[NM|SHM]_am_send_hdr`, + `MPIDI_[NM|SHM]_am_isend`, `MPIDI_[NM|SHM]_am_send_hdr_reply`, and + `MPIDI_[NM|SHM]_am_isend_reply` handle the eager and rendezvous + handshake paths. +* **Capability queries**: `MPIDI_[NM|SHM]_am_hdr_max_sz`, + `MPIDI_[NM|SHM]_am_eager_limit`, and + `MPIDI_[NM|SHM]_am_eager_buf_limit` report transport limits that drive + protocol selection. +* **Decision helpers**: `MPIDI_[NM|SHM]_am_check_eager` validates whether + a particular payload can use the eager path and `MPIDI_[NM|SHM]_am_can_do_tag` + advertises tag-matching support. `MPIDI_[NM|SHM]_am_get_data_copy_cb` + returns the netmod/shmmod-specific receive buffer copy callback. +* **Tag matching accelerators**: `MPIDI_[NM|SHM]_am_tag_send` and + `MPIDI_[NM|SHM]_am_tag_recv` implement optimized tag matching for + transports that support it. +* **Request lifecycle hooks**: `MPIDI_[NM|SHM]_am_request_init` and + `MPIDI_[NM|SHM]_am_request_finalize` must be invoked to prepare and + clean up device-specific request bookkeeping. + +Refer to `ch4_api.txt` when adding new functionality to ensure that any +new active message entry points are reflected in the generated glue +code. The callback typedefs and registration helpers used by these +handlers are defined in `src/mpid/ch4/src/mpidig.h`. -/* largest header (in bytes) supported by the nm/shm */ -MPI_Aint MPIDI_[NM|SHM]_am_hdr_max_sz(void) - -/* eager size supported by transport (only used internally by nm/shm) */ -MPI_Aint MPIDI_[NM|SHM]_am_eager_limit(void) - -/* eager buffer size supported by transport, used to assert pipeline protocol will work(?) */ -MPI_Aint MPIDI_[NM|SHM]_am_eager_buf_limit(void) - -/* return true/false if pt2pt message can be sent eagerly */ -bool MPIDI_[NM|SHM]_am_check_eager(MPI_Aint am_hdr_sz, MPI_Aint data_sz, - const void *data, MPI_Aint count, - MPI_Datatype datatype, MPIR_Request * sreq) - -/****************** Callback APIs ******************/ - -/* target-side message callback */ -typedef int (*MPIDIG_am_target_msg_cb) (int handler_id, void *am_hdr, - void *data, MPI_Aint data_sz, - int is_local, int is_async, MPIR_Request ** req); - -/* target-side completion callback */ -typedef int (*MPIDIG_am_target_cmpl_cb) (MPIR_Request * req); - -/* origin-side completion callback */ -typedef int (*MPIDIG_am_origin_cb) (MPIR_Request * req); -``` #### SHM diff --git a/doc/wiki/source_code/Building_MPICH_For_Development.md b/doc/wiki/source_code/Building_MPICH_For_Development.md index 3f75b4ad212..08914b00bce 100644 --- a/doc/wiki/source_code/Building_MPICH_For_Development.md +++ b/doc/wiki/source_code/Building_MPICH_For_Development.md @@ -168,7 +168,7 @@ doing what's known as a ["VPATH build"](http://www.gnu.org/software/make/manual/ Let's assume you have your source in some directory like: `/foo/bar/mpich-trunk`. If you are using an git version of the code you will need to do an ./autogen.sh in this source directory (see -[here](Getting_And_Building_MPICH#Setting_up_the_build_environment "wikilink")). +[here](Github.md#setting-up-the-build-environment)). Now let's say that you want to build two versions, one with a supported thread level of `MPI_THREAD_SINGLE` and one with `MPI_THREAD_MULTIPLE`. @@ -192,4 +192,4 @@ The following wiki pages contain additional platform-specific build information. - [Blue Gene/Q](BGQ.md) - - [x86 and POWER using the Parallel Environment Runtime Edition](PE_RTE) + - [x86 and POWER using the Parallel Environment Runtime Edition](PE_RTE.md) diff --git a/doc/wiki/source_code/Github.md b/doc/wiki/source_code/Github.md index 40376b8eb02..8e4f30ac501 100644 --- a/doc/wiki/source_code/Github.md +++ b/doc/wiki/source_code/Github.md @@ -7,7 +7,7 @@ git clone https://github.com/pmodels/mpich.git (for non-core developers wi git clone git@github.com:pmodels/mpich.git (for core developers with commit rights) ``` -See the [Version Control System](Version_Control_System.md) page for more information about using +See the [Git workflow guide](Git_Workflow.md) for more information about using our current version control system. ## Setting Up The Build Environment @@ -15,7 +15,7 @@ our current version control system. Doing a git clone may not be sufficient to initialize necessary git submodules. To retrieve submodules, run -` git submodule update --init` +`git submodule update --init --recursive` The git repository does not contain any of the "derived" files, including the configure scripts and the C++ and Fortran 77 language @@ -35,10 +35,10 @@ find . -name configure -print | xargs rm ./autogen.sh ``` -The autoconf macros and the configure.in scripts now require the +The autoconf macros and the configure.ac scripts now require the following: - - **autoconf version 2.67 (or higher)** + - **autoconf version 2.69 (or higher)** - **automake version 1.12.3 (or higher)** - **GNU libtool version 2.4 (or higher)** @@ -75,7 +75,7 @@ Otherwise `/usr` will be assumed as a default. correctly for you, but not always.** If you change one of the files that is the source for a derived file, -such as a `configure.in` file, you will need to rebuild the derived file +such as a `configure.ac` file, you will need to rebuild the derived file (e.g., the corresponding configure file). The safest way to do this is to rerun autogen.sh: