Hi,
The latest merges from trunk to v1.7 broke v1.7 for openib:
*08:08:36* btl_openib_xrc.c:80: warning: 'ibv_close_xrc_domain' is
deprecated (declared at
/usr/include/infiniband/ofa_verbs.h:102)*08:08:36* CC
btl_openib_fd.lo*08:08:36* CC btl_openib_ip.lo*08:08:36* CC
connect/btl
I'll have to fix it when I return on Wed - trivial fix. Thanks!
On Mon, Nov 4, 2013 at 10:27 PM, Mike Dubman wrote:
>
> Hi,
> The latest merges from trunk to v1.7 broke v1.7 for openib:
>
> *08:08:36* btl_openib_xrc.c:80: warning: 'ibv_close_xrc_domain' is deprecated
> (declared at /usr/inclu
One thing that might help these problems: could you please complete the
move from openib/connect to common/ofacm? It is a little frustrating to
have to maintain two duplicate codes that are literally copy/paste versions
of each other.
I'd be happy to approve the CMR when available.
On Tue, Nov
Excellent, we must be one of the most reactive communities out there. This
patch went all the way from trunk into the stable in a blazing 6 hours
interval. Didn’t even got a chance of getting one good-old nightly test.
Unfortunately the patch might have some issues, our configure bails out with
Is that related to this patch? I was about to bisect this error:
checking for compiler familyid... 2
checking for compiler familyname... INTEL
checking for compiler version... 1375113743
checking for compiler version_str...
/usr/projects/hpctools/hjelmn/ompi-trunk-git/configure: line 27938: 20130
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
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
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
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
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 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:
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
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
13 matches
Mail list logo
