hummm
i intentionally did not swap the two 32 bits (!)
from the top level, what we have is :
typedef struct {
union {
uint64_t opal;
struct {
uint32_t jobid;
uint32_t vpid;
} orte;
} meta_process_name_t;
OPAL is agnostic about jobid and vpid.
jobid and vpid are set in ORTE/MPI and OPAL is used only
to transport the 64 bits
/* opal_process_name_t and orte_process_name_t are often casted into each
other */
at ORTE/MPI level, jobid and vpid are set individually
/* e.g. we do *not* do something like opal = jobid | (vpid<<32) */
this is why everything works fine on homogeneous clusters regardless
endianness.
now in heterogeneous cluster, thing get a bit trickier ...
i was initially unhappy with my commit and i think i found out why :
this is an abstraction violation !
the two 32 bits are not swapped by OPAL because this is what is expected by
the ORTE/OMPI.
now i d like to suggest the following lightweight approach :
at OPAL, use #if protected htonll/ntohll
(e.g. swap the two 32bits)
do the trick at the ORTE level :
simply replace
struct orte_process_name_t {
orte_jobid_t jobid;
orte_vpid_t vpid;
};
with
#if OPAL_ENABLE_HETEROGENEOUS_SUPPORT && !defined(WORDS_BIGENDIAN)
struct orte_process_name_t {
orte_vpid_t vpid;
orte_jobid_t jobid;
};
#else
struct orte_process_name_t {
orte_jobid_t jobid;
orte_vpid_t vpid;
};
#endif
so we keep OPAL agnostic about how the uint64_t is really used at the upper
level.
an other option is to make OPAL aware of jobid and vpid but this is a bit
more heavyweight imho.
i'll try this today and make sure it works.
any thoughts ?
Cheers,
Gilles
On Wed, Aug 6, 2014 at 8:17 AM, Ralph Castain <[email protected]> wrote:
> Ah yes, so it is - sorry I missed that last test :-/
>
> On Aug 5, 2014, at 10:50 AM, George Bosilca <[email protected]> wrote:
>
> The code committed by Gilles is correctly protected for big endian (
> https://svn.open-mpi.org/trac/ompi/changeset/32425). I was merely
> pointing out that I think he should also swap the 2 32 bits in his
> implementation.
>
> George.
>
>
>
> On Tue, Aug 5, 2014 at 1:32 PM, Ralph Castain <[email protected]> wrote:
>
>>
>> On Aug 5, 2014, at 10:23 AM, George Bosilca <[email protected]> wrote:
>>
>> On Tue, Aug 5, 2014 at 1:15 PM, Ralph Castain <[email protected]> wrote:
>>
>>> Hmmm...wouldn't that then require that you know (a) the other side is
>>> little endian, and (b) that you are on a big endian? Otherwise, you wind up
>>> with the same issue in reverse, yes?
>>>
>>
>> This is similar to the 32 bits ntohl that we are using in other parts of
>> the project. Any little endian participant will do the conversion, while
>> every big endian participant will use an empty macro instead.
>>
>>
>>> In the ORTE methods, we explicitly set the fields (e.g., jobid =
>>> ntohl(remote-jobid)) to get around this problem. I missed that he did it by
>>> location instead of named fields - perhaps we should do that instead?
>>>
>>
>> As soon as we impose the ORTE naming scheme at the OPAL level (aka. the
>> notion of jobid and vpid) this approach will become possible.
>>
>>
>> Not proposing that at all so long as the other method will work without
>> knowing the other side's endianness. Sounds like your approach should work
>> fine as long as Gilles adds a #if so big endian defines the macro away
>>
>>
>> George.
>>
>>
>>
>>>
>>>
>>> On Aug 5, 2014, at 10:06 AM, George Bosilca <[email protected]> wrote:
>>>
>>> Technically speaking, converting a 64 bits to a big endian
>>> representation requires the swap of the 2 32 bits parts. So the correct
>>> approach would have been:
>>> uint64_t htonll(uint64_t v)
>>> {
>>> return ((((uint64_t)ntohl(n)) << 32 | (uint64_t)ntohl(n >> 32));
>>> }
>>>
>>> George.
>>>
>>>
>>>
>>> On Tue, Aug 5, 2014 at 5:52 AM, Ralph Castain <[email protected]> wrote:
>>>
>>>> FWIW: that's exactly how we do it in ORTE
>>>>
>>>> On Aug 4, 2014, at 10:25 PM, Gilles Gouaillardet <
>>>> [email protected]> wrote:
>>>>
>>>> George,
>>>>
>>>> i confirm there was a problem when running on an heterogeneous cluster,
>>>> this is now fixed in r32425.
>>>>
>>>> i am not convinced i chose the most elegant way to achieve the desired
>>>> result ...
>>>> could you please double check this commit ?
>>>>
>>>> Thanks,
>>>>
>>>> Gilles
>>>>
>>>> On 2014/08/02 0:14, George Bosilca wrote:
>>>>
>>>> Gilles,
>>>>
>>>> The design of the BTL move was to let the opal_process_name_t be agnostic
>>>> to what is stored inside, and all accesses should be done through the
>>>> provided accessors. Thus, big endian or little endian doesn’t make a
>>>> difference, as long as everything goes through the accessors.
>>>>
>>>> I’m skeptical about the support of heterogeneous environments in the
>>>> current code, so I didn’t pay much attention to handling the case in the
>>>> TCP BTL. But in case we do care it is enough to make the 2 macros point
>>>> to something meaningful instead of being empty (bswap_64 or something).
>>>>
>>>> George.
>>>>
>>>> On Aug 1, 2014, at 06:52 , Gilles Gouaillardet
>>>> <[email protected]> <[email protected]> wrote:
>>>>
>>>>
>>>> George and Ralph,
>>>>
>>>> i am very confused whether there is an issue or not.
>>>>
>>>>
>>>> anyway, today Paul and i ran basic tests on big endian machines and did
>>>> not face any issue related to big endianness.
>>>>
>>>> so i made my homework, digged into the code, and basically,
>>>> opal_process_name_t is used as an orte_process_name_t.
>>>> for example, in ompi_proc_init :
>>>>
>>>> OMPI_CAST_ORTE_NAME(&proc->super.proc_name)->jobid =
>>>> OMPI_PROC_MY_NAME->jobid;
>>>> OMPI_CAST_ORTE_NAME(&proc->super.proc_name)->vpid = i;
>>>>
>>>> and with
>>>>
>>>> #define OMPI_CAST_ORTE_NAME(a) ((orte_process_name_t*)(a))
>>>>
>>>> so as long as an opal_process_name_t is used as an orte_process_name_t,
>>>> there is no problem,
>>>> regardless the endianness of the homogenous cluster we are running on.
>>>>
>>>> for the sake of readability (and for being pedantic too ;-) ) in r32357,
>>>> &proc_temp->super.proc_name
>>>> could be replaced with
>>>> OMPI_CAST_ORTE_NAME(&proc_temp->super.proc_name)
>>>>
>>>>
>>>>
>>>> That being said, in btl/tcp, i noticed :
>>>>
>>>> in mca_btl_tcp_component_recv_handler :
>>>>
>>>> opal_process_name_t guid;
>>>> [...]
>>>> /* recv the process identifier */
>>>> retval = recv(sd, (char *)&guid, sizeof(guid), 0);
>>>> if(retval != sizeof(guid)) {
>>>> CLOSE_THE_SOCKET(sd);
>>>> return;
>>>> }
>>>> OPAL_PROCESS_NAME_NTOH(guid);
>>>>
>>>> and in mca_btl_tcp_endpoint_send_connect_ack :
>>>>
>>>> /* send process identifier to remote endpoint */
>>>> opal_process_name_t guid = btl_proc->proc_opal->proc_name;
>>>>
>>>> OPAL_PROCESS_NAME_HTON(guid);
>>>> if(mca_btl_tcp_endpoint_send_blocking(btl_endpoint, &guid,
>>>> sizeof(guid)) !=
>>>>
>>>> and with
>>>>
>>>> #define OPAL_PROCESS_NAME_NTOH(guid)
>>>> #define OPAL_PROCESS_NAME_HTON(guid)
>>>>
>>>>
>>>> i had no time yet to test yet, but for now, i can only suspect :
>>>> - there will be an issue with the tcp btl on an heterogeneous cluster
>>>> - for this case, the fix is to have a different version of the
>>>> OPAL_PROCESS_NAME_xTOy
>>>> on little endian arch if heterogeneous mode is supported.
>>>>
>>>>
>>>>
>>>> does that make sense ?
>>>>
>>>> Cheers,
>>>>
>>>> Gilles
>>>>
>>>>
>>>> On 2014/07/31 1:29, George Bosilca wrote:
>>>>
>>>> The underlying structure changed, so a little bit of fiddling is normal.
>>>> Instead of using a field in the ompi_proc_t you are now using a field down
>>>> in opal_proc_t, a field that simply cannot have the same type as before
>>>> (orte_process_name_t).
>>>>
>>>> George.
>>>>
>>>>
>>>>
>>>> On Wed, Jul 30, 2014 at 12:19 PM, Ralph Castain <[email protected]>
>>>> <[email protected]> wrote:
>>>>
>>>>
>>>> George - my point was that we regularly tested using the method in that
>>>> routine, and now we have to do something a little different. So it is an
>>>> "issue" in that we have to make changes across the code base to ensure we
>>>> do things the "new" way, that's all
>>>>
>>>> On Jul 30, 2014, at 9:17 AM, George Bosilca <[email protected]>
>>>> <[email protected]> wrote:
>>>>
>>>> No, this is not going to be an issue if the opal_identifier_t is used
>>>> correctly (aka only via the exposed accessors).
>>>>
>>>> George.
>>>>
>>>>
>>>>
>>>> On Wed, Jul 30, 2014 at 12:09 PM, Ralph Castain <[email protected]>
>>>> <[email protected]> wrote:
>>>>
>>>>
>>>> Yeah, my fix won't work for big endian machines - this is going to be an
>>>> issue across the code base now, so we'll have to troll and fix it. I was
>>>> doing the minimal change required to fix the trunk in the meantime.
>>>>
>>>> On Jul 30, 2014, at 9:06 AM, George Bosilca <[email protected]>
>>>> <[email protected]> wrote:
>>>>
>>>> Yes. opal_process_name_t has basically no meaning by itself, it is a 64
>>>> bits storage location used by the upper layer to save some local key that
>>>> can be later used to extract information. Calling the OPAL level compare
>>>> function might be a better fit there.
>>>>
>>>> George.
>>>>
>>>>
>>>>
>>>> On Wed, Jul 30, 2014 at 11:50 AM, Gilles Gouaillardet
>>>> <[email protected]> wrote:
>>>>
>>>>
>>>> Ralph,
>>>>
>>>> was it really that simple ?
>>>>
>>>> proc_temp->super.proc_name has type opal_process_name_t :
>>>> typedef opal_identifier_t opal_process_name_t;
>>>> typedef uint64_t opal_identifier_t;
>>>>
>>>> *but*
>>>>
>>>> item_ptr->peer has type orte_process_name_t :
>>>> struct orte_process_name_t {
>>>> orte_jobid_t jobid;
>>>> orte_vpid_t vpid;
>>>> };
>>>>
>>>> bottom line, is r32357 still valid on a big endian arch ?
>>>>
>>>> Cheers,
>>>>
>>>> Gilles
>>>>
>>>>
>>>> On Wed, Jul 30, 2014 at 11:49 PM, Ralph Castain <[email protected]>
>>>> <[email protected]>
>>>> wrote:
>>>>
>>>>
>>>> I just fixed this one - all that was required was an ampersand as the
>>>> name was being passed into the function instead of a pointer to the name
>>>>
>>>> r32357
>>>>
>>>> On Jul 30, 2014, at 7:43 AM, Gilles GOUAILLARDET
>>>> <[email protected]> wrote:
>>>>
>>>> Rolf,
>>>>
>>>> r32353 can be seen as a suspect...
>>>> Even if it is correct, it might have exposed the bug discussed in #4815
>>>> even more (e.g. we hit the bug 100% after the fix)
>>>>
>>>> does the attached patch to #4815 fixes the problem ?
>>>>
>>>> If yes, and if you see this issue as a showstopper, feel free to commit
>>>> it and drop a note to #4815
>>>> ( I am afk until tomorrow)
>>>>
>>>> Cheers,
>>>>
>>>> Gilles
>>>>
>>>> Rolf vandeVaart <[email protected]> <[email protected]> wrote:
>>>>
>>>> Just an FYI that my trunk version (r32355) does not work at all anymore
>>>> if I do not include "--mca coll ^ml". Here is a stack trace from the
>>>> ibm/pt2pt/send test running on a single node.
>>>>
>>>>
>>>>
>>>> (gdb) where
>>>>
>>>> #0 0x00007f6c0d1321d0 in ?? ()
>>>>
>>>> #1 <signal handler called>
>>>>
>>>> #2 0x00007f6c183abd52 in orte_util_compare_name_fields (fields=15
>>>> '\017', name1=0x192350001, name2=0xbaf76c) at
>>>> ../../orte/util/name_fns.c:522
>>>>
>>>> #3 0x00007f6c0bea17be in bcol_basesmuma_smcm_allgather_connection
>>>> (sm_bcol_module=0x7f6bf3b68040, module=0xb3d200, peer_list=0x7f6c0c0a6748,
>>>> back_files=0x7f6bf3ffd6c8,
>>>>
>>>> comm=0x6037a0, input=..., base_fname=0x7f6c0bea2606
>>>> "sm_payload_mem_", map_all=false) at
>>>> ../../../../../ompi/mca/bcol/basesmuma/bcol_basesmuma_smcm.c:237
>>>>
>>>> #4 0x00007f6c0be98307 in bcol_basesmuma_bank_init_opti
>>>> (payload_block=0xbc0f60, data_offset=64, bcol_module=0x7f6bf3b68040,
>>>> reg_data=0xba28c0)
>>>>
>>>> at
>>>> ../../../../../ompi/mca/bcol/basesmuma/bcol_basesmuma_buf_mgmt.c:302
>>>>
>>>> #5 0x00007f6c0cced386 in mca_coll_ml_register_bcols
>>>> (ml_module=0xba5c40) at
>>>> ../../../../../ompi/mca/coll/ml/coll_ml_module.c:510
>>>>
>>>> #6 0x00007f6c0cced68f in ml_module_memory_initialization
>>>> (ml_module=0xba5c40) at
>>>> ../../../../../ompi/mca/coll/ml/coll_ml_module.c:558
>>>>
>>>> #7 0x00007f6c0ccf06b1 in ml_discover_hierarchy (ml_module=0xba5c40) at
>>>> ../../../../../ompi/mca/coll/ml/coll_ml_module.c:1539
>>>>
>>>> #8 0x00007f6c0ccf4e0b in mca_coll_ml_comm_query (comm=0x6037a0,
>>>> priority=0x7fffe7991b58) at
>>>> ../../../../../ompi/mca/coll/ml/coll_ml_module.c:2963
>>>>
>>>> #9 0x00007f6c18cc5b09 in query_2_0_0 (component=0x7f6c0cf50940,
>>>> comm=0x6037a0, priority=0x7fffe7991b58, module=0x7fffe7991b90)
>>>>
>>>> at ../../../../ompi/mca/coll/base/coll_base_comm_select.c:372
>>>>
>>>> #10 0x00007f6c18cc5ac8 in query (component=0x7f6c0cf50940,
>>>> comm=0x6037a0, priority=0x7fffe7991b58, module=0x7fffe7991b90)
>>>>
>>>> at ../../../../ompi/mca/coll/base/coll_base_comm_select.c:355
>>>>
>>>> #11 0x00007f6c18cc59d2 in check_one_component (comm=0x6037a0,
>>>> component=0x7f6c0cf50940, module=0x7fffe7991b90)
>>>>
>>>> at ../../../../ompi/mca/coll/base/coll_base_comm_select.c:317
>>>>
>>>> #12 0x00007f6c18cc5818 in check_components (components=0x7f6c18f46ef0,
>>>> comm=0x6037a0) at
>>>> ../../../../ompi/mca/coll/base/coll_base_comm_select.c:281
>>>>
>>>> #13 0x00007f6c18cbe3c9 in mca_coll_base_comm_select (comm=0x6037a0) at
>>>> ../../../../ompi/mca/coll/base/coll_base_comm_select.c:117
>>>>
>>>> #14 0x00007f6c18c52301 in ompi_mpi_init (argc=1, argv=0x7fffe79924c8,
>>>> requested=0, provided=0x7fffe79922e8) at
>>>> ../../ompi/runtime/ompi_mpi_init.c:918
>>>>
>>>> #15 0x00007f6c18c86e92 in PMPI_Init (argc=0x7fffe799234c,
>>>> argv=0x7fffe7992340) at pinit.c:84
>>>>
>>>> #16 0x0000000000401056 in main (argc=1, argv=0x7fffe79924c8) at
>>>> send.c:32
>>>>
>>>> (gdb) up
>>>>
>>>> #1 <signal handler called>
>>>>
>>>> (gdb) up
>>>>
>>>> #2 0x00007f6c183abd52 in orte_util_compare_name_fields (fields=15
>>>> '\017', name1=0x192350001, name2=0xbaf76c) at
>>>> ../../orte/util/name_fns.c:522
>>>>
>>>> 522 if (name1->jobid < name2->jobid) {
>>>>
>>>> (gdb) print name1
>>>>
>>>> $1 = (const orte_process_name_t *) 0x192350001
>>>>
>>>> (gdb) print *name1
>>>>
>>>> Cannot access memory at address 0x192350001
>>>>
>>>> (gdb) print name2
>>>>
>>>> $2 = (const orte_process_name_t *) 0xbaf76c
>>>>
>>>> (gdb) print *name2
>>>>
>>>> $3 = {jobid = 2452946945, vpid = 1}
>>>>
>>>> (gdb)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: devel [mailto:[email protected] <[email protected]>
>>>>
>>>> <[email protected]> <[email protected]>] On Behalf Of
>>>> Gilles
>>>>
>>>>
>>>> Gouaillardet
>>>> Sent: Wednesday, July 30, 2014 2:16 AM
>>>> To: Open MPI Developers
>>>> Subject: Re: [OMPI devel] trunk compilation errors in jenkins
>>>> George,
>>>> #4815 is indirectly related to the move :
>>>> in bcol/basesmuma, we used to compare ompi_process_name_t, and now
>>>> we (try to) compare an ompi_process_name_t and an opal_process_name_t
>>>> (which causes a glory SIGSEGV)
>>>> i proposed a temporary patch which is both broken and unelegant, could
>>>>
>>>> you
>>>>
>>>>
>>>> please advise a correct solution ?
>>>> Cheers,
>>>> Gilles
>>>> On 2014/07/27 7:37, George Bosilca wrote:
>>>>
>>>> If you have any issue with the move, I’ll be happy to help and/or
>>>>
>>>> support
>>>>
>>>>
>>>> you on your last move toward a completely generic BTL. To facilitate
>>>>
>>>> your
>>>>
>>>>
>>>> work I exposed a minimalistic set of OMPI information at the OPAL
>>>>
>>>> level. Take
>>>>
>>>>
>>>> a look at opal/util/proc.h for more info, but please try not to expose
>>>>
>>>> more.
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing [email protected]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this post: http://www.open-
>>>>
>>>> <http://www.open-mpi.org/community/lists/devel/2014/07/15348.php>
>>>> <http://www.open-mpi.org/community/lists/devel/2014/07/15348.php>
>>>>
>>>> mpi.org/community/lists/devel/2014/07/15348.php
>>>>
>>>> <http://www.open-mpi.org/community/lists/devel/2014/07/15348.php>
>>>> <http://www.open-mpi.org/community/lists/devel/2014/07/15348.php>
>>>> ------------------------------
>>>> This email message is for the sole use of the intended recipient(s)
>>>> and may contain confidential information. Any unauthorized review, use,
>>>> disclosure or distribution is prohibited. If you are not the intended
>>>> recipient, please contact the sender by reply email and destroy all copies
>>>> of the original message.
>>>> ------------------------------
>>>> _______________________________________________
>>>> devel mailing [email protected]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this
>>>> post:http://www.open-mpi.org/community/lists/devel/2014/07/15355.php
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing [email protected]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this
>>>> post:http://www.open-mpi.org/community/lists/devel/2014/07/15356.php
>>>>
>>>> _______________________________________________
>>>> devel mailing [email protected]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this
>>>> post:http://www.open-mpi.org/community/lists/devel/2014/07/15363.php
>>>>
>>>> _______________________________________________
>>>> devel mailing [email protected]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this
>>>> post:http://www.open-mpi.org/community/lists/devel/2014/07/15364.php
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing [email protected]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this
>>>> post:http://www.open-mpi.org/community/lists/devel/2014/07/15365.php
>>>>
>>>> _______________________________________________
>>>> devel mailing [email protected]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this
>>>> post:http://www.open-mpi.org/community/lists/devel/2014/07/15366.php
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing [email protected]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this
>>>> post:http://www.open-mpi.org/community/lists/devel/2014/07/15367.php
>>>>
>>>> _______________________________________________
>>>> devel mailing [email protected]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this post:
>>>> http://www.open-mpi.org/community/lists/devel/2014/07/15368.php
>>>>
>>>> _______________________________________________
>>>> devel mailing [email protected]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this post:
>>>> http://www.open-mpi.org/community/lists/devel/2014/08/15446.php
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing [email protected]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this post:
>>>> http://www.open-mpi.org/community/lists/devel/2014/08/15454.php
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> [email protected]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this post:
>>>> http://www.open-mpi.org/community/lists/devel/2014/08/15509.php
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> [email protected]
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Link to this post:
>>>> http://www.open-mpi.org/community/lists/devel/2014/08/15514.php
>>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> [email protected]
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Link to this post:
>>> http://www.open-mpi.org/community/lists/devel/2014/08/15518.php
>>>
>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> [email protected]
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Link to this post:
>>> http://www.open-mpi.org/community/lists/devel/2014/08/15519.php
>>>
>>
>> _______________________________________________
>> devel mailing list
>> [email protected]
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/08/15520.php
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> [email protected]
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/08/15521.php
>>
>
> _______________________________________________
> devel mailing list
> [email protected]
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/08/15523.php
>
>
>
> _______________________________________________
> devel mailing list
> [email protected]
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/08/15526.php
>
