-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16/11/13 02:00, Jeff Squyres (jsquyres) wrote:
> 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
> (
On Nov 15, 2013, at 5:21 AM, George Bosilca 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
On Nov 6, 2013, at 16:26 , Nathan Hjelm wrote:
> On Wed, Nov 06, 2013 at 02:06:15AM +, Jeff Squyres (jsquyres) wrote:
>> On Nov 5, 2013, at 2:59 PM, George Bosilca wrote:
>>
>>> I have a question regarding the extension of this concept to multi-BTL
>>> runs. Granted we will have to have a
On Wed, Nov 06, 2013 at 02:06:15AM +, Jeff Squyres (jsquyres) wrote:
> On Nov 5, 2013, at 2:59 PM, George Bosilca wrote:
>
> > I have a question regarding the extension of this concept to multi-BTL
> > runs. Granted we will have to have a local indexing of BTL (I'm not
> > concerned about thi
Ok, I changed the name to "btl_usnic" in SVN (and can change it again if a
better suggestion comes by...).
On Nov 5, 2013, at 8:24 PM, Paul Hargrove wrote:
> I stand by my previous "vote"
>
> "btl_usnic" gets 90% of my vote.
> "btl_usnic_enum" gets 10%.
> "btl_usnic_*_enum" gets nada.
>
> Ra
I stand by my previous "vote"
"btl_usnic" gets 90% of my vote.
"btl_usnic_enum" gets 10%.
"btl_usnic_*_enum" gets nada.
Rationale:
While Jeff is correct that the string can legally contain '*', I would
imagine that users would like to have the ability to use wildcards (or even
full regular expres
Hmm. "_enum" has possibilities.
How about using a * in the name, to represent where the match is? E.G.,
btl_usnic_*_enum?
It's a string, so it's not just limited to letters and underscores.
Sent from my phone. No type good.
On Nov 5, 2013, at 6:26 PM, "Paul Hargrove"
mailto:phhargr...@lbl.g
On Tue, Nov 5, 2013 at 6:00 PM, Jeff Squyres (jsquyres)
wrote:
> On Nov 5, 2013, at 2:54 PM, Paul Hargrove wrote:
>
> > If this approach is to be adopted by other components (and perhaps other
> MPIs), then it would be important for the enumeration variable name to be
> derived in a UNIFORM way:
On Nov 5, 2013, at 2:59 PM, George Bosilca wrote:
> I have a question regarding the extension of this concept to multi-BTL
> runs. Granted we will have to have a local indexing of BTL (I'm not
> concerned about this). But how do we ensure the naming is globally
> consistent (in the sense that all
On Nov 5, 2013, at 2:54 PM, Paul Hargrove wrote:
> If this approach is to be adopted by other components (and perhaps other
> MPIs), then it would be important for the enumeration variable name to be
> derived in a UNIFORM way:
> __SOMETHING
> Without a fixed value for "SOMETHING" somebody
I like the idea. I do have some question not necessarily related to
your proposal, but to how we can use the information you propose to
expose.
I have a question regarding the extension of this concept to multi-BTL
runs. Granted we will have to have a local indexing of BTL (I'm not
concerned about
Jeff,
If this approach is to be adopted by other components (and perhaps other
MPIs), then it would be important for the enumeration variable name to be
derived in a UNIFORM way:
__SOMETHING
Without a fixed value for "SOMETHING" somebody will need to read sources
(or documentation) to make the
WHAT: suggestion for how to expose multiple MPI_T pvar values for a given
variable.
WHY: so that we have a common convention across OMPI (and possibly set a
precedent for other MPI implementations...?).
WHERE: ompi/mca/btl/usnic, but if everyone likes it, potentially elsewhere in
OMPI
TIMEOUT
13 matches
Mail list logo
