On Nov 15, 2013, at 5:21 AM, George Bosilca <bosi...@icl.utk.edu> wrote:
>> There is no need to ensure global consistency unless you declare the pvar to >> have a global scope (MCA_BASE_VAR_SCOPE_GROUP, MCA_BASE_VAR_SCOPE_GROUP_EQ, >> MCA_BASE_VAR_SCOPE_ALL, or MCA_BASE_VAR_SCOPE_ALL_EQ.) > > They clearly can’t be of any _EQ scope. After reading the entire chapter in > the MPI 3.1 I’m not sure how the defined scope applies to the naming Correct -- there is no relationship between the pvar name and the scope. > or to the relationship between their values. Correct -- just like above, there's no standardized relationship between the scope and a pvar's values. Keep in mind: all I'm proposing is a *convention*; I assume it won't actually go into the standard. Specifically: there's no way in the current standard to express the relationship that I want to express. So I'm proposing a convention that tools can look for. That's all. > That being said, the consistency I was looking for is somehow different. What > I really wanted is a way, not based on the physical naming but based on some > logical naming, that will allow a tool to “globally” make sense of the > information exposed. Having separate (on each node) local information about > the local usnic0 provide little information about any communication > inconsistencies. Knowing the fact that there are many pending sends on my > local usnic0 is interesting, but being able to link this information with a > number of pending receives/other MPI_T on the peers sharing the same network > layer will be much more valuable knowledge, providing better insight on what > is going on each network layer. Agreed. All I've done is the former (just exposing underlying network stats). Got any ideas about how to link such underlying stats to MPI layer stuff? This actually raises a point that MPI_T makes you read individual pvars separately -- there's no "atomically read this array of pvars" functionality. That could lead to inconsistent results (e.g., first you read a network stat, and then you read an MPI layer stat -- but under the covers, the network stat could have changed by the time you read the MPI layer stat). Hmm. -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
