Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

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