1
1
openmpi/ompi/mca/pml/cm/pml_cm_component.c

188 строки
5.9 KiB
C
Исходник Обычный вид История

/*
* Copyright (c) 2006-2007 The Trustees of Indiana University and Indiana
* University Research and Technology
* Corporation. All rights reserved.
* Copyright (c) 2004-2007 The University of Tennessee and The University
* of Tennessee Research Foundation. All rights
* reserved.
* Copyright (c) 2004-2006 The Regents of the University of California.
* All rights reserved.
== Highlights == 1. New mpifort wrapper compiler: you can utilize mpif.h, use mpi, and use mpi_f08 through this one wrapper compiler 1. mpif77 and mpif90 still exist, but are sym links to mpifort and may be removed in a future release 1. The mpi module has been re-implemented and is significantly "mo' bettah" 1. The mpi_f08 module offers many, many improvements over mpif.h and the mpi module This stuff is coming from a VERY long-lived mercurial branch (3 years!); it'll almost certainly take a few SVN commits and a bunch of testing before I get it correctly committed to the SVN trunk. == More details == Craig Rasmussen and I have been working with the MPI-3 Fortran WG and Fortran J3 committees for a long, long time to make a prototype MPI-3 Fortran bindings implementation. We think we're at a stable enough state to bring this stuff back to the trunk, with the goal of including it in OMPI v1.7. Special thanks go out to everyone who has been incredibly patient and helpful to us in this journey: * Rolf Rabenseifner/HLRS (mastermind/genius behind the entire MPI-3 Fortran effort) * The Fortran J3 committee * Tobias Burnus/gfortran * Tony !Goetz/Absoft * Terry !Donte/Oracle * ...and probably others whom I'm forgetting :-( There's still opportunities for optimization in the mpi_f08 implementation, but by and large, it is as far along as it can be until Fortran compilers start implementing the new F08 dimension(..) syntax. Note that gfortran is currently unsupported for the mpi_f08 module and the new mpi module. gfortran users will a) fall back to the same mpi module implementation that is in OMPI v1.5.x, and b) not get the new mpi_f08 module. The gfortran maintainers are actively working hard to add the necessary features to support both the new mpi_f08 module and the new mpi module implementations. This will take some time. As mentioned above, ompi/mpi/f77 and ompi/mpi/f90 no longer exist. All the fortran bindings implementations have been collated under ompi/mpi/fortran; each implementation has its own subdirectory: {{{ ompi/mpi/fortran/ base/ - glue code mpif-h/ - what used to be ompi/mpi/f77 use-mpi-tkr/ - what used to be ompi/mpi/f90 use-mpi-ignore-tkr/ - new mpi module implementation use-mpi-f08/ - new mpi_f08 module implementation }}} There's also a prototype 6-function-MPI implementation under use-mpi-f08-desc that emulates the new F08 dimension(..) syntax that isn't fully available in Fortran compilers yet. We did that to prove it to ourselves that it could be done once the compilers fully support it. This directory/implementation will likely eventually replace the use-mpi-f08 version. Other things that were done: * ompi_info grew a few new output fields to describe what level of Fortran support is included * Existing Fortran examples in examples/ were renamed; new mpi_f08 examples were added * The old Fortran MPI libraries were renamed: * libmpi_f77 -> libmpi_mpifh * libmpi_f90 -> libmpi_usempi * The configury for Fortran was consolidated and significantly slimmed down. Note that the F77 env variable is now IGNORED for configure; you should only use FC. Example: {{{ shell$ ./configure CC=icc CXX=icpc FC=ifort ... }}} All of this work was done in a Mercurial branch off the SVN trunk, and hosted at Bitbucket. This branch has got to be one of OMPI's longest-running branches. Its first commit was Tue Apr 07 23:01:46 2009 -0400 -- it's over 3 years old! :-) We think we've pulled in all relevant changes from the OMPI trunk (e.g., Fortran implementations of the new MPI-3 MPROBE stuff for mpif.h, use mpi, and use mpi_f08, and the recent Fujitsu Fortran patches). I anticipate some instability when we bring this stuff into the trunk, simply because it touches a LOT of code in the MPI layer in the OMPI code base. We'll try our best to make it as pain-free as possible, but please bear with us when it is committed. This commit was SVN r26283.
2012-04-18 19:57:29 +04:00
* Copyright (c) 2010-2012 Cisco Systems, Inc. All rights reserved.
* $COPYRIGHT$
*
* Additional copyrights may follow
*
* $HEADER$
*/
#include "ompi_config.h"
#include "pml_cm.h"
Update libevent to the 2.0 series, currently at 2.0.7rc. We will update to their final release when it becomes available. Currently known errors exist in unused portions of the libevent code. This revision passes the IBM test suite on a Linux machine and on a standalone Mac. This is a fairly intrusive change, but outside of the moving of opal/event to opal/mca/event, the only changes involved (a) changing all calls to opal_event functions to reflect the new framework instead, and (b) ensuring that all opal_event_t objects are properly constructed since they are now true opal_objects. Note: Shiqing has just returned from vacation and has not yet had a chance to complete the Windows integration. Thus, this commit almost certainly breaks Windows support on the trunk. However, I want this to have a chance to soak for as long as possible before I become less available a week from today (going to be at a class for 5 days, and thus will only be sparingly available) so we can find and fix any problems. Biggest change is moving the libevent code from opal/event to a new opal/mca/event framework. This was done to make it much easier to update libevent in the future. New versions can be inserted as a new component and tested in parallel with the current version until validated, then we can remove the earlier version if we so choose. This is a statically built framework ala installdirs, so only one component will build at a time. There is no selection logic - the sole compiled component simply loads its function pointers into the opal_event struct. I have gone thru the code base and converted all the libevent calls I could find. However, I cannot compile nor test every environment. It is therefore quite likely that errors remain in the system. Please keep an eye open for two things: 1. compile-time errors: these will be obvious as calls to the old functions (e.g., opal_evtimer_new) must be replaced by the new framework APIs (e.g., opal_event.evtimer_new) 2. run-time errors: these will likely show up as segfaults due to missing constructors on opal_event_t objects. It appears that it became a typical practice for people to "init" an opal_event_t by simply using memset to zero it out. This will no longer work - you must either OBJ_NEW or OBJ_CONSTRUCT an opal_event_t. I tried to catch these cases, but may have missed some. Believe me, you'll know when you hit it. There is also the issue of the new libevent "no recursion" behavior. As I described on a recent email, we will have to discuss this and figure out what, if anything, we need to do. This commit was SVN r23925.
2010-10-24 22:35:54 +04:00
#include "opal/mca/event/event.h"
#include "opal/mca/base/mca_base_param.h"
#include "ompi/mca/mtl/mtl.h"
#include "ompi/mca/mtl/base/base.h"
#include "ompi/mca/pml/base/pml_base_bsend.h"
#include "pml_cm_sendreq.h"
#include "pml_cm_recvreq.h"
#include "pml_cm_component.h"
static int mca_pml_cm_component_register(void);
static int mca_pml_cm_component_open(void);
static int mca_pml_cm_component_close(void);
static mca_pml_base_module_t* mca_pml_cm_component_init( int* priority,
bool enable_progress_threads, bool enable_mpi_threads);
static int mca_pml_cm_component_fini(void);
mca_pml_base_component_2_0_0_t mca_pml_cm_component = {
/* First, the mca_base_component_t struct containing meta
* information about the component itself */
{
MCA_PML_BASE_VERSION_2_0_0,
"cm", /* MCA component name */
OMPI_MAJOR_VERSION, /* MCA component major version */
OMPI_MINOR_VERSION, /* MCA component minor version */
OMPI_RELEASE_VERSION, /* MCA component release version */
mca_pml_cm_component_open, /* component open */
mca_pml_cm_component_close, /* component close */
NULL,
mca_pml_cm_component_register,
},
{
/* This component is not checkpoint ready */
MCA_BASE_METADATA_PARAM_NONE
},
mca_pml_cm_component_init, /* component init */
mca_pml_cm_component_fini /* component finalize */
};
/* Array of send completion callback - one per send type
* These are called internally by the library when the send
* is completed from its perspective.
*/
void (*send_completion_callbacks[MCA_PML_BASE_SEND_SIZE])
(struct mca_mtl_request_t *mtl_request) =
{ mca_pml_cm_send_request_completion,
mca_pml_cm_send_request_completion,
mca_pml_cm_send_request_completion,
mca_pml_cm_send_request_completion,
mca_pml_cm_send_request_completion } ;
static int
mca_pml_cm_component_register(void)
{
mca_base_param_reg_int(&mca_pml_cm_component.pmlm_version,
"free_list_num",
"Initial size of request free lists",
false,
false,
4,
&ompi_pml_cm.free_list_num);
mca_base_param_reg_int(&mca_pml_cm_component.pmlm_version,
"free_list_max",
"Maximum size of request free lists",
false,
false,
-1,
&ompi_pml_cm.free_list_max);
mca_base_param_reg_int(&mca_pml_cm_component.pmlm_version,
"free_list_inc",
"Number of elements to add when growing request free lists",
false,
false,
64,
&ompi_pml_cm.free_list_inc);
mca_base_param_reg_int(&mca_pml_cm_component.pmlm_version,
"priority",
"CM PML selection priority",
false,
false,
10,
&ompi_pml_cm.default_priority);
return OPAL_SUCCESS;
}
static int
mca_pml_cm_component_open(void)
{
int ret;
ret = ompi_mtl_base_open();
if (OMPI_SUCCESS == ret) {
/* If no MTL components initialized CM component can be unloaded */
if (0 == opal_list_get_size(&ompi_mtl_base_components_opened)) {
ret = OPAL_ERR_NOT_AVAILABLE;
}
}
return ret;
}
static int
mca_pml_cm_component_close(void)
{
return ompi_mtl_base_close();
}
static mca_pml_base_module_t*
mca_pml_cm_component_init(int* priority,
bool enable_progress_threads,
bool enable_mpi_threads)
{
int ret;
if((*priority) > ompi_pml_cm.default_priority) {
*priority = ompi_pml_cm.default_priority;
return NULL;
}
*priority = ompi_pml_cm.default_priority;
opal_output_verbose( 10, 0,
"in cm pml priority is %d\n", *priority);
/* find a useable MTL */
ret = ompi_mtl_base_select(enable_progress_threads, enable_mpi_threads);
if (OMPI_SUCCESS != ret) {
*priority = -1;
return NULL;
} else if((strcmp(ompi_mtl_base_selected_component->mtl_version.mca_component_name, "psm") == 0) ||
(strcmp(ompi_mtl_base_selected_component->mtl_version.mca_component_name, "mxm") == 0)) {
/*
* If MTL is MXM or PSM then up our priority
* For every other communication layer having MTLs and BTLs, the user/admin
* may still select PML/ob1 (BTLs) or PML/cm (MTLs) if preferable for the app/site.
*/
*priority = 30;
}
/* update our tag / context id max values based on MTL
information */
ompi_pml_cm.super.pml_max_contextid = ompi_mtl->mtl_max_contextid;
ompi_pml_cm.super.pml_max_tag = ompi_mtl->mtl_max_tag;
return &ompi_pml_cm.super;
}
static int
mca_pml_cm_component_fini(void)
{
if (NULL != ompi_mtl) {
return OMPI_MTL_CALL(finalize(ompi_mtl));
}
return OMPI_SUCCESS;
}