Jeff Squyres wrote:
On Aug 16, 2007, at 11:48 AM, Tim Prins wrote:
+#define ORTE_RML_TAG_UDAPL 25
+#define ORTE_RML_TAG_OPENIB 26
+#define ORTE_RML_TAG_MVAPI 27
I think that UDAPL, OPENIB, MVAPI should not appear anywhere in the
ORTE layer ...
I tend to agree with you. However, the precedent has been set long ago
to put all these constants in this file (i.e. there is
ORTE_RML_TAG_WIREUP and ORTE_RML_TAG_SM_BACK_FILE_CREATED which are
only
used in OMPI), and it makes sense to have all tags defined in one
place.
I think George's point is that the names UDAPL, OPENIB, MVAPI are all
specific to the OMPI layer and refer to specific components. The
generic action WIREUP was probably somewhat forgivable, but
SM_BACK_FILE_CREATED is probably the same kind of abstraction break
as UDAPL/OPENIB/MVAPI, which is your point.
So you're both right. :-) But Tim's falling back on an older (and
unfortunately bad) precedent. It would be nice to not extend that
bad precedent, IMHO...
I really don't care where the constants are defined, but they do need to
be unique. I think it is easiest if all the constants are stored in one
file, but if someone else wants to chop them up, that's fine with me. We
would just have to be more careful when adding new constants to check
both files.
If we end up doing the runtime services layer, all the ompi tags would
be defined in the RSL, and this will become moot.
True. We will need a robust tag reservation system, though, to
guarantee that every process gets the same tag values (e.g., if udapl
is available on some nodes but not others, will that cause openib to
have different values on different nodes? And so on).
Not really. All that is needed is a list of constants (similar to the
one in rml_types.h). If a rsl component doesn't like the particular
constant tag values, they can do whatever they want in their
implementation, as long as a messages sent on a tag is received on the
same tag.
Tim
