openmpi

configure.m4

Remove the old configure option for disabling full rte support - we now use the OMPI rte framework for such purposes

2013-02-28 01:35:55 +00:00

help-oob-tcp.txt

Can't use show_help as the RML has already been enabled, but we haven't successfully connected back to the HNP. So use opal_output instead and hardwire the message.

2014-09-16 22:21:02 +00:00

Makefile.am

Use the correct abstraction layer name for the data dirs

2014-05-08 14:32:24 +00:00

oob_tcp_common.c

Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.

2014-06-06 02:24:17 +00:00

oob_tcp_common.h

Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.

2014-06-06 02:24:17 +00:00

oob_tcp_component.c

Properly protect the MCA parameters being registered by the OOB/TCP component when IPv6 is enabled

2014-09-02 14:53:00 +00:00

oob_tcp_component.h

Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.

2014-06-06 02:24:17 +00:00

oob_tcp_connection.c

Can't use show_help as the RML has already been enabled, but we haven't successfully connected back to the HNP. So use opal_output instead and hardwire the message.

2014-09-16 22:21:02 +00:00

oob_tcp_connection.h

Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.

2014-06-06 02:24:17 +00:00

oob_tcp_hdr.h

Don't use "size_t" for the nbytes field in the header - use uint32_t to ensure that ntohl/htonl correctly match it

2013-12-23 21:39:49 +00:00

oob_tcp_listener.c

Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.

2014-06-06 02:24:17 +00:00

oob_tcp_listener.h

As per the RFC, bring in the ORTE async progress code and the rewrite of OOB:

2013-08-22 16:37:40 +00:00

oob_tcp_peer.h

Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.

2014-06-06 02:24:17 +00:00

oob_tcp_ping.h

Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.

2014-06-06 02:24:17 +00:00

oob_tcp_sendrecv.c

Try to resolve the simultaneous connection problem by being a little more careful about the choice of returned status when a connection is refused. As before, have the higher vpid of the two peers retry the connection, while the lower one waits. This can happen in a couple of places, so try to hit them all. Since this is hard to test, will ask Gilles to give it a try since he's the one who is seeing it.

2014-09-16 18:59:36 +00:00

oob_tcp_sendrecv.h

Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.

2014-06-06 02:24:17 +00:00

oob_tcp.c

Remove an unnecessary optimization that can cause more trouble than it's worth - just try all the addresses that are given to us.

2014-08-20 20:58:07 +00:00

oob_tcp.h

Now that the BTLs are moving down to OPAL and becoming available to ORTE, there no longer is a need/desire to push performance in the OOB/TCP component. So we don't need multiple modules driving NICs in parallel, and can drop all the complicated distribution logic. Fall back to the simplified single module model, but retain the ability to run that module in its own progress thread if so directed.

2014-06-06 02:24:17 +00:00