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
>> used in OMPI), and it makes sense to have all tags defined in one
> 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
>> 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