Re: [OMPI devel] open ib dependency question

2008-07-02 Thread Jeff Squyres
That is the IBCM library for the IBCM CPC -- IB connection manager  
stuff.


It's not *necessary*; you could use the OOB CPC if you want to.

That being said, OMPI currently builds support for it (and links it  
in) if it finds the right headers and library files.  We don't  
currently have configury to disable this behavior (and *not* build  
RDMACM and/or IBCM support).


Do you have a problem / need to disable building support for IBCM?



On Jul 2, 2008, at 12:02 PM, Don Kerr wrote:



It appears that the mca_btl_openib.so  has a dependency on  
libibcm.so.  Is this necessary?



___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel



--
Jeff Squyres
Cisco Systems



[OMPI devel] Open MPI v1.2.7rc2 has been posted

2008-07-02 Thread Tim Mattox
Hi All,
The second release candidate of Open MPI v1.2.7 is now available:

 http://www.open-mpi.org/software/ompi/v1.2/

Please run it through it's paces as best you can.
-- 
Tim Mattox, Ph.D. - http://homepage.mac.com/tmattox/
 tmat...@gmail.com || timat...@open-mpi.org
 I'm a bright... http://www.the-brights.net/


[OMPI devel] open ib dependency question

2008-07-02 Thread Don Kerr


It appears that the mca_btl_openib.so  has a dependency on libibcm.so.  
Is this necessary?  






Re: [OMPI devel] CARTO slot definition

2008-07-02 Thread Lenny Verkhovsky
Hi, all,
since there are no objections I will commit the patch to trunk and 1.3
branch.
see also comments below.


2008/6/29 Ralph Castain :

> I believe this would help reduce the confusion a great deal. While the
> current carto syntax is the expected for a mathematician, computer users and
> developers have a well-established definition for the term "node" that
> conflicts with that used in carto.
>
> Some thoughts to add:  in carto, do you want to create a definition for
> CORE as well as SOCKET? That way, someone could provide info down to either
> level of granularity. In our subsequent frameworks, we could assume that all
> cores in a socket have the same graph analysis unless the core was described
> separately.
>

For my best knowledge all cores on the same socket have same distance on the
graph, so I dont see any need to add more code and definitions for now.


>
>
> Likewise, you may want to support a NODE that describes connectivity
> between computing nodes. Again, one could assume that all sockets on the
> node share the same graph unless the socket was described separately – or
> perhaps allow someone to describe the graph for the socket to get to the
> edge of the node, and then let the node description handle comm between
> nodes.
>

Interesting idea, I suppose it can be implemented in the future.


>
>
> Up to you – I'm just trying to think of ways we could bring this closer to
> the topo description required in other modules elsewhere in the code to
> avoid having multiple files.
>
> Ralph
>




>
>
> On 6/29/08 7:44 AM, "Lenny Verkhovsky"  wrote:
>
>   Hi all,
> We have ambiquite definitions of "slot" in rankfile, hostfile and carto
> components.
> Since "slot" is well defined as a processor in the hostfile and rankfile (
> "slot" is defined as processing unit which can be processor number or
> socket:core pair ).
> I propose to change carto file syntax and make it more graph oriented. This
> won't have any effect on the code.
>
> In new carto syntax
>
> NODE will be changed to EDGE
> CONNECTION will be changed to BRANCH
> SLOT will be changed to SOCKET.
>
> Any comments are welcome.
> few words about carto can be found at
> https://svn.open-mpi.org/trac/ompi/wiki/OnHostTopologyDescription
>
>   Index: opal/mca/carto/file/help-opal-carto-file.txt
> ===
> --- opal/mca/carto/file/help-opal-carto-file.txt(revision 18772)
> +++ opal/mca/carto/file/help-opal-carto-file.txt(working copy)
> @@ -27,27 +27,27 @@
>  #
>  [expected node type]
> -File: %s line: %d expected node type (free string). received %s
> +File: %s line: %d expected Edge type (free string). received %s
>  #
>  [expected node name]
> -File: %s line: %d expected Node name (free string). received %s
> +File: %s line: %d expected Edge name (free string). received %s
>  #
>  [expected Connection]
> -File: %s line: %d expected Node connection (node name:weight). received %s
> +File: %s line: %d expected Edge branch (edge name:weight). received %s
>  #
>  [expected deceleration]
> -File: %s line: %d expected Node deceleration (NODE) or connection
> deceleration (CONNECTION). received %s
> +File: %s line: %d expected Edge declaration (EDGE) or branch declaration
> (BRANCH). received %s
>  #
>  [incorrect connection]
> -File: %s line: %d - %s - incorrect connection
> +File: %s line: %d - %s - incorrect branch
>  #
>  [vertex not found]
> -File: %s line: %d - Node %s is not in the graph
> +File: %s line: %d - Edge %s is not in the graph
>  #
>  [unknown token]
> Index: opal/mca/carto/file/carto_file_lex.l
> ===
> --- opal/mca/carto/file/carto_file_lex.l(revision 18772)
> +++ opal/mca/carto/file/carto_file_lex.l(working copy)
> @@ -80,13 +80,13 @@
>
> -NODE   { carto_file_value.sval = yytext;
> +EDGE   { carto_file_value.sval = yytext;
>   return OPAL_CARTO_FILE_NODE_DECELERATION; }
> -CONNECTION { carto_file_value.sval = yytext;
> +BRANCH { carto_file_value.sval = yytext;
>   return OPAL_CARTO_FILE_CONNECTION_DECELERATION; }
> -CON_BI_DIR { carto_file_value.sval = yytext;
> +BRANCH_BI_DIR { carto_file_value.sval = yytext;
>   return OPAL_CARTO_FILE_BIDIRECTION_CONNECTION; }
>  [0-9]  { carto_file_value.ival = atol(yytext);
> Index: opal/mca/carto/file/carto_file.h
> ===
> --- opal/mca/carto/file/carto_file.h(revision 18772)
> +++ opal/mca/carto/file/carto_file.h(working copy)
> @@ -21,49 +21,49 @@
>  /**
>   * @file#this is a comment
>  # Node declaration   Node type (Free string)   Node name (Free string)
> -# (Reserve word) (slot is a reserve word   (free string)
> -# for CPU slot)
> +# (Reserve word) (socket is a reserve