btl_openib_connect_rdmacm_reject_causes_connect_error (yes, it's
still long -- on purpose :-) )
* Add INI file parameter rdmacm_reject_causes_connect_error
* Now only treat CONNECT_ERROR events as a REJECT if:
* It's on a connection where we were expecting a REJECT, ''and''
* The MCA parameter is true ''or'' the INI parameter for this
device is true
* Set the INI parameter for true for the NE020
This commit was SVN r20459.
errhandler (should be initializing _errors_throw_exceptions, not
_are_fatal). This bug was not a huge tragedy because the only real
problem is that _are_fatal has the wrong string name with it (because
MPI::Init fixes up the _errors_throw_exceptions later).
This commit was SVN r20458.
versions of the NE driver will report the OUI while others will report
the PCI ID. We'll put in the Intel values when we get them (may not
be for a few more weeks).
This commit was SVN r20457.
properly at all. NetEffect's current driver (OFED 1.4.0) will return
a CONNECT_ERROR event to the initiator rather than the REJECTED event.
Doh! Additionally -- unfortunately -- NetEffect's vendor_id and
vendor_part_id are reported as 0 in OFED 1.4.0, so we can't
automatically detect these cards and work around the problem. So all
we can do is add a new MCA parameter
(btl_openib_connect_rdmacm_ignore_connect_errors -- yes, it's long on
purpose ;-) ) that says that if we get a CONNECT_ERROR, bascially
treat it exactly as a REJECT for the WRONG_DIRECTION reason (which is
a "good" reject). This allows OMPI to function with NetEffect/Intel
cards on OFED 1.4.0.
Note that NetEffect has been bought by Intel; I'm waiting for
information from them to update the ini file for their new OUI/PCI
ID's and/or new vendor_part_id values.
This commit was SVN r20454.
Fix a mistake in the dpm that hardcoded the update of routes to the HNP. This needs to be done by the individual routing modules so they can take whatever action is required - which will usually include updating the HNP, but might not...and might include additional steps. New routing modules are coming that violated this assumption, so it had to be moved back into init_routes.
All current routed modules know what to do - anyone with routed modules not in the current trunk may need to adjust them (see any of the current routed modules for examples of what to do).
This commit was SVN r20427.
have different sizes:
1. Do not modify the read only parameter of the Fortran MPI interface (i.e be
standard compliant).
2. When Fortran integers are 64 bits long, don't generate unlawful code.
Thanks to Christoph van Wullen for the bug report.
This commit was SVN r20420.
Revert r20381 as two header files are "special".
This commit was SVN r20382.
The following SVN revision numbers were found above:
r20381 --> open-mpi/ompi@25b25aef41
lock -- therefore move the OPAL_THREAD_UNLOCK after
the if-OMPI_ERR_TEMP_OUT_OF_RESOURCE block.
- As mca_rcache_rb_mru_delete is the only setter of rc, move the
error-check right after mca_rcache_rb_mru_delete.
- Removed a few nitty ompi/info/info.h and orte/util/show_help.h
This commit was SVN r20355.
* New "op" MPI layer framework
* Addition of the MPI_REDUCE_LOCAL proposed function (for MPI-2.2)
= Op framework =
Add new "op" framework in the ompi layer. This framework replaces the
hard-coded MPI_Op back-end functions for (MPI_Op, MPI_Datatype) tuples
for pre-defined MPI_Ops, allowing components and modules to provide
the back-end functions. The intent is that components can be written
to take advantage of hardware acceleration (GPU, FPGA, specialized CPU
instructions, etc.). Similar to other frameworks, components are
intended to be able to discover at run-time if they can be used, and
if so, elect themselves to be selected (or disqualify themselves from
selection if they cannot run). If specialized hardware is not
available, there is a default set of functions that will automatically
be used.
This framework is ''not'' used for user-defined MPI_Ops.
The new op framework is similar to the existing coll framework, in
that the final set of function pointers that are used on any given
intrinsic MPI_Op can be a mixed bag of function pointers, potentially
coming from multiple different op modules. This allows for hardware
that only supports some of the operations, not all of them (e.g., a
GPU that only supports single-precision operations).
All the hard-coded back-end MPI_Op functions for (MPI_Op,
MPI_Datatype) tuples still exist, but unlike coll, they're in the
framework base (vs. being in a separate "basic" component) and are
automatically used if no component is found at runtime that provides a
module with the necessary function pointers.
There is an "example" op component that will hopefully be useful to
those writing meaningful op components. It is currently
.ompi_ignore'd so that it doesn't impinge on other developers (it's
somewhat chatty in terms of opal_output() so that you can tell when
its functions have been invoked). See the README file in the example
op component directory. Developers of new op components are
encouraged to look at the following wiki pages:
https://svn.open-mpi.org/trac/ompi/wiki/devel/Autogenhttps://svn.open-mpi.org/trac/ompi/wiki/devel/CreateComponenthttps://svn.open-mpi.org/trac/ompi/wiki/devel/CreateFramework
= MPI_REDUCE_LOCAL =
Part of the MPI-2.2 proposal listed here:
https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/24
is to add a new function named MPI_REDUCE_LOCAL. It is very easy to
implement, so I added it (also because it makes testing the op
framework pretty easy -- you can do it in serial rather than via
parallel reductions). There's even a man page!
This commit was SVN r20280.
* If the accumulate is local, make it short-circuit the request path. Accumulate requires local
ops due to its window rules, so this is likely to help a bunch (on the codes I"m messing
with at least)
* Due a better job at flushing everything that can go out on the wire in a resource constrained problem
* Move some debugging values around to make large problems somewhat easier to deal with
This commit was SVN r20277.
and ::SEEK_SET (duh); that's why it's listed in constants.h. So put
that back and make it (static const int) rather than extern, and then
remove the instantiation from mpicxx.cc. Ditto for the other 2.
This commit was SVN r20251.
The following Trac tickets were found above:
Ticket 623 --> https://svn.open-mpi.org/trac/ompi/ticket/623
in mpicxx.h a while ago, but somehow accidentally left "extern const
int" for SEEK_SET (and friends) in constants.h. This commit removes
the extraneous "extern" versions.
This commit was SVN r20250.
The following Trac tickets were found above:
Ticket 623 --> https://svn.open-mpi.org/trac/ompi/ticket/623
to grow to. Without this change, jobs with np>120 get errors.
This does not change anything for np<16 jobs. It only comes into
play with larger np count on a node. I imagine that this can be
scaled back in the future if the usage of memory in the sm
btl is improved.
This fixes trac:1449.
This commit was SVN r20230.
The following Trac tickets were found above:
Ticket 1449 --> https://svn.open-mpi.org/trac/ompi/ticket/1449
