Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] RFC: Use of ompi_proc_t flags field
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-01-21 14:02:48

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 work.
> Please feel free to comment and/or request more information.
> Ralph
> _______________________________________________
> devel mailing list
> devel_at_[hidden]

Jeff Squyres
Cisco Systems