Appropriate mapper components will be used, along with a file
describing which nodes are in which CU etc. So it won't be so much a
matter of discovery as pre-knowledge.
On Jan 21, 2009, at 12:02 PM, Jeff Squyres wrote:
> Sounds reasonable. How do you plan to discover this information?
> On Jan 21, 2009, at 9:58 AM, Ralph Castain wrote:
>> What: Extend the current use of the ompi_proc_t flags field
>> (without changing the field itself)
>> Why: Provide more atomistic sense of locality to support new
>> collective/BTL components
>> Where: Add macros to define and check the various flag fields in
>> ompi/proc.h. Revise the orte_ess.proc_is_local API to return a
>> uint8_t instead of bool.
>> When: For OMPI v1.4
>> Timeout: COB Fri, Feb 6, 2009
>> The current ompi_proc_t structure has a uint8_t flags field in it.
>> Only one bit of this field is currently used to flag that a proc is
>> "local". In the current context, "local" is constrained to mean
>> "local to this node".
>> New collectives and BTL components under development by LANL (in
>> partnership with others) require a greater degree of granularity on
>> the term "local". For our work, we need to know if the proc is on
>> the same socket, PC board, node, switch, and CU (computing unit).
>> We therefore propose to define some of the unused bits to flag
>> these "local" conditions. This will not extend the field's size,
>> nor impact any other current use of the field.
>> Our intent is to add #define's to designate which bits stand for
>> which local condition. To make it easier to use, we will add a set
>> of macros that test the specific bit - e.g.,
>> OMPI_PROC_ON_LOCAL_SOCKET. These can be used in the code base to
>> clearly indicate which sense of locality is being considered.
>> We would also modify the orte_ess modules so that each returns a
>> uint8_t (to match the ompi_proc_t field) that contains a complete
>> description of the locality of this proc. Obviously, not all
>> environments will be capable of providing such detailed info. Thus,
>> getting a "false" from a test for "on_local_socket" may simply
>> indicate a lack of knowledge. This is acceptable for our purposes
>> as the algorithm will simply perform sub-optimally, but will still
>> Please feel free to comment and/or request more information.
>> devel mailing list
> Jeff Squyres
> Cisco Systems
> devel mailing list