1
1
Граф коммитов

23 Коммитов

Автор SHA1 Сообщение Дата
Rainer Keller
d81443cc5a - On the way to get the BTLs split out and lessen dependency on orte:
Often, orte/util/show_help.h is included, although no functionality
   is required -- instead, most often opal_output.h, or               
   orte/mca/rml/rml_types.h                                           
   Please see orte_show_help_replacement.sh commited next.            

 - Local compilation (Linux/x86_64) w/ -Wimplicit-function-declaration
   actually showed two *missing* #include "orte/util/show_help.h"     
   in orte/mca/odls/base/odls_base_default_fns.c and                  
   in orte/tools/orte-top/orte-top.c                                  
   Manually added these.                                              

   Let's have MTT the last word.

This commit was SVN r20557.
2009-02-14 02:26:12 +00:00
Ralph Castain
9613b3176c Effectively revert the orte_output system and return to direct use of opal_output at all levels. Retain the orte_show_help subsystem to allow aggregation of show_help messages at the HNP.
After much work by Jeff and myself, and quite a lot of discussion, it has become clear that we simply cannot resolve the infinite loops caused by RML-involved subsystems calling orte_output. The original rationale for the change to orte_output has also been reduced by shifting the output of XML-formatted vs human readable messages to an alternative approach.

I have globally replaced the orte_output/ORTE_OUTPUT calls in the code base, as well as the corresponding .h file name. I have test compiled and run this on the various environments within my reach, so hopefully this will prove minimally disruptive.

This commit was SVN r18619.
2008-06-09 14:53:58 +00:00
Ralph Castain
c992e99035 Remove the tags from orte_output_open and the filtering operation from orte_output - this will be handled differently to improve the XML output interface
This commit was SVN r18557.
2008-06-03 14:24:01 +00:00
Jeff Squyres
e7ecd56bd2 This commit represents a bunch of work on a Mercurial side branch. As
such, the commit message back to the master SVN repository is fairly
long.

= ORTE Job-Level Output Messages =

Add two new interfaces that should be used for all new code throughout
the ORTE and OMPI layers (we already make the search-and-replace on
the existing ORTE / OMPI layers):

 * orte_output(): (and corresponding friends ORTE_OUTPUT,
   orte_output_verbose, etc.)  This function sends the output directly
   to the HNP for processing as part of a job-specific output
   channel.  It supports all the same outputs as opal_output()
   (syslog, file, stdout, stderr), but for stdout/stderr, the output
   is sent to the HNP for processing and output.  More on this below.
 * orte_show_help(): This function is a drop-in-replacement for
   opal_show_help(), with two differences in functionality:
   1. the rendered text help message output is sent to the HNP for
      display (rather than outputting directly into the process' stderr
      stream)
   1. the HNP detects duplicate help messages and does not display them
      (so that you don't see the same error message N times, once from
      each of your N MPI processes); instead, it counts "new" instances
      of the help message and displays a message every ~5 seconds when
      there are new ones ("I got X new copies of the help message...")

opal_show_help and opal_output still exist, but they only output in
the current process.  The intent for the new orte_* functions is that
they can apply job-level intelligence to the output.  As such, we
recommend that all new ORTE and OMPI code use the new orte_*
functions, not thei opal_* functions.

=== New code ===

For ORTE and OMPI programmers, here's what you need to do differently
in new code:

 * Do not include opal/util/show_help.h or opal/util/output.h.
   Instead, include orte/util/output.h (this one header file has
   declarations for both the orte_output() series of functions and
   orte_show_help()).
 * Effectively s/opal_output/orte_output/gi throughout your code.
   Note that orte_output_open() takes a slightly different argument
   list (as a way to pass data to the filtering stream -- see below),
   so you if explicitly call opal_output_open(), you'll need to
   slightly adapt to the new signature of orte_output_open().
 * Literally s/opal_show_help/orte_show_help/.  The function signature
   is identical.

=== Notes ===

 * orte_output'ing to stream 0 will do similar to what
   opal_output'ing did, so leaving a hard-coded "0" as the first
   argument is safe.
 * For systems that do not use ORTE's RML or the HNP, the effect of
   orte_output_* and orte_show_help will be identical to their opal
   counterparts (the additional information passed to
   orte_output_open() will be lost!).  Indeed, the orte_* functions
   simply become trivial wrappers to their opal_* counterparts.  Note
   that we have not tested this; the code is simple but it is quite
   possible that we mucked something up.

= Filter Framework =

Messages sent view the new orte_* functions described above and
messages output via the IOF on the HNP will now optionally be passed
through a new "filter" framework before being output to
stdout/stderr.  The "filter" OPAL MCA framework is intended to allow
preprocessing to messages before they are sent to their final
destinations.  The first component that was written in the filter
framework was to create an XML stream, segregating all the messages
into different XML tags, etc.  This will allow 3rd party tools to read
the stdout/stderr from the HNP and be able to know exactly what each
text message is (e.g., a help message, another OMPI infrastructure
message, stdout from the user process, stderr from the user process,
etc.).

Filtering is not active by default.  Filter components must be
specifically requested, such as:

{{{
$ mpirun --mca filter xml ...
}}}

There can only be one filter component active.

= New MCA Parameters =

The new functionality described above introduces two new MCA
parameters:

 * '''orte_base_help_aggregate''': Defaults to 1 (true), meaning that
   help messages will be aggregated, as described above.  If set to 0,
   all help messages will be displayed, even if they are duplicates
   (i.e., the original behavior).
 * '''orte_base_show_output_recursions''': An MCA parameter to help
   debug one of the known issues, described below.  It is likely that
   this MCA parameter will disappear before v1.3 final.

= Known Issues =

 * The XML filter component is not complete.  The current output from
   this component is preliminary and not real XML.  A bit more work
   needs to be done to configure.m4 search for an appropriate XML
   library/link it in/use it at run time.
 * There are possible recursion loops in the orte_output() and
   orte_show_help() functions -- e.g., if RML send calls orte_output()
   or orte_show_help().  We have some ideas how to fix these, but
   figured that it was ok to commit before feature freeze with known
   issues.  The code currently contains sub-optimal workarounds so
   that this will not be a problem, but it would be good to actually
   solve the problem rather than have hackish workarounds before v1.3 final.

This commit was SVN r18434.
2008-05-13 20:00:55 +00:00
Galen Shipman
b378c8c12c return success.
This commit was SVN r17612.
2008-02-27 02:15:53 +00:00
Tim Mattox
ec82d01555 Add a missing extern keyword that prevented compilation on OS X.
This commit was SVN r13853.
2007-02-28 20:26:34 +00:00
Sven Stork
870740efe2 - proper export symbols that are required by other components.
This commit was SVN r13841.
2007-02-28 12:51:55 +00:00
Brian Barrett
09cc9e4941 properly compute starting offset -- the lb will be included in the offset, so we don't need
both.

Refs trac:864

This commit was SVN r13494.

The following Trac tickets were found above:
  Ticket 864 --> https://svn.open-mpi.org/trac/ompi/ticket/864
2007-02-05 18:12:18 +00:00
Brian Barrett
846eed84f1 When receiving a message, need to account for the fact that the displacement
of the first entry might not be the start of the user's buffer.  This is
similar to what ompi_convertor_unpack does.  This is the solution for
the test case attached to ticket #690.

Refs trac:690

This commit was SVN r13397.

The following Trac tickets were found above:
  Ticket 690 --> https://svn.open-mpi.org/trac/ompi/ticket/690
2007-01-31 18:18:19 +00:00
George Bosilca
f3de2e1a82 Keep the fast path as short as possible.
This commit was SVN r12476.
2006-11-07 23:56:32 +00:00
George Bosilca
110d07b7d3 Small optimization or zero length messages.
This commit was SVN r12414.
2006-11-02 19:10:28 +00:00
George Bosilca
126a68dc9a Big datatype commit. Remove all unused features of the datatype engine. As the memory
allocation logic is completely done outside the data-type engine (in the PML) there is
no need for any special case inside the data-type engine. There is less arguments for
the ompi_convertor_pack and ompi_convertor_unpack as well (the last field free_after is
not required anymore as there is no memory allocated in the engine itself). This change
affect all components using datatypes. I test most of them, but it might happens that I
miss some ... If it's the case please let me know (don't shoot the pianist!!).

This commit was SVN r12331.
2006-10-26 23:11:26 +00:00
George Bosilca
18d119bc06 No more warnings.
This commit was SVN r12181.
2006-10-18 21:10:11 +00:00
Brian Barrett
6d414f2d44 * use the MTL-specific output stream for all error messages
* use OPAL_OUTPUT_VERBOSE rather than printfs for debugging messages

This commit was SVN r11227.
2006-08-16 16:28:58 +00:00
Brian Barrett
a21769bbfb * careful with the opal_output when no components are selected
This commit was SVN r11093.
2006-08-02 21:13:33 +00:00
Brian Barrett
bc16f462b9 * print framework and component name during load errors
* return a failure from mtl select code if we don't have a
  component that can run

This commit was SVN r11092.
2006-08-02 20:59:58 +00:00
Brian Barrett
ca5bd805db * add missing continuation line
This commit was SVN r10758.
2006-07-12 14:33:08 +00:00
Galen Shipman
5085061475 don't call unpack when we received directly into the user buffer.. the
convertor doesn't handle it properly
continue peeking until we don't get anything else.. 
close the endpoint before closing the library.. 
add a blocking send that uses mx_test .. 

This commit was SVN r10684.
2006-07-06 19:54:13 +00:00
Brian Barrett
ef6b7e170f * make mtl datatype wrapper code inline functions
This commit was SVN r10678.
2006-07-06 15:58:07 +00:00
Galen Shipman
2217fd4003 reset receive request convertor for persistent requests
We can always call unpack.. 

This commit was SVN r10677.
2006-07-06 15:13:26 +00:00
Galen Shipman
fe480cd003 change mask bits and don't call convertor if we received directly into the
user buffer.. 

This commit was SVN r10665.
2006-07-05 21:10:09 +00:00
George Bosilca
402a03d229 Add a .h dependency in order to remove a warning when we compile without --enable-debug.
This commit was SVN r10646.
2006-07-04 04:53:38 +00:00
Brian Barrett
47725c9b02 * Add new PML (CM) and network drivers (MTL) for high speed
interconnects that provide matching logic in the library.
  Currently includes support for MX and some support for
  Portals
* Fix overuse of proc_pml pointer on the ompi_proc structuer, 
  splitting into proc_pml for pml data and proc_bml for
  the BML endpoint data
* bug fixes in bsend init code, which wasn't being used by
  the OB1 or DR PMLs...

This commit was SVN r10642.
2006-07-04 01:20:20 +00:00