Hey all -
Thought I would give you guys a heads up on some code that will be
coming into the trunk in the not too distant future (hopefully
tomorrow?). The changes revolve around the RML/OOB interface and
include:
* General TCP cleanup for OPAL / ORTE
* Simplifying the OOB by moving much of the logic into the RML
* Allowing the OOB RML component to do routing of messages
* Adding a component framework for handling routing tables
* Moving the xcast functionality from the OOB base to its own
framework
The IPv6 code did some things that I (and I know George) didn't
like. Some functions had their interface change depending on whether
IPv6 support was enabled (taking either an sockaddr_in or
sockaddr_in6 instead of just a sockaddr) and we were inconsistent
about storage sizes. I've added a bunch of compatibility code to
opal_config_bottom.h so that we can always have sockaddr_storage and
some of the required IPv6 defines, which drastically simplified the
IPv6 code in the TCP OOB.
Previously, the OOB and RML component interfaces were essentially
equivalent. This isn't surprising, as the RML was added at the last
minute as a wrapper around the OOB as a forward looking way of
solving multi-cell architectures. The interface into the OOB was
also strange, requiring the upper layer (the RML) to call base
functions that did a bit of work, then called the component. With
this change, all the base code has been moved into the RML, and the
OOB interface has been simplified by removing all the blocking and
dss buffer communication. The RML now handles the implementation of
blocking sends and dss buffer communication. This not only greatly
simplifies writing an OOB component, but removes the base code in the
oob, which was causing problems as it implied that there was one and
only one oob component active at a time, which some people are
apparently trying to break (by having multiple OOB components alive).
The OOB RML can now also route messages, using a new framework (the
routed framework) for determining how a message should be routed.
Currently, only direct routing is supported, although that will
change in the near future. The not-so-long term goal is to allow MPI
processes to talk to each other and to the HNP through their local
daemon, rather than directly. This will drastically reduce the
number of sockets open in the system, which can only help with the
speed thing.
Finally, we moved the xcast functionality out of the OOB base and
into its own framework. It really didn't make sense to have it in
the OOB base, as it didn't do anything OOB specific and just utilized
the RML to move data around. By moving it to its own framework, we
can more easily experiment with new xcast protocols (using the
component infrastructure, rather than the games Ralph currently has
to play using MCA parameters and if statements). It also makes a
clearer distinction as to which components are responsible for which
functionality.
Anyway, that's where we're at. You can take a look at the code in
the temporary branch bwb-oob-rml-cleanup, although it currently does
not work for singletons due to some merge conflicts from last night.
This will be resolved before the merge back into the trunk, obviously.
Brian
--
Brian W. Barrett
Networking Team, CCS-1
Los Alamos National Laboratory
