Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r29055 - in trunk/ompi/mca: btl btl/smcuda common/cuda pml/ob1
Yes, I agree that the CUDA support is more intrusive and ends up in different areas. The problem is that the changes could not be simply isolated in a BTL. 1. To support the direct movement of GPU buffers, we often utilize copying into host memory and then out of host memory. These copies have to be done utilizing the cuMemcpy() functions rather than the memcpy() function. This is why some changes ended up in the opal datatype area. Must of that copying is driven by the convertor. 2. I added support for doing an asynchronous copy into and out of host buffers. This ended up touching datatype, PML, and BTL layers. 3. A GPU buffer may utilize a different protocol than a HOST buffer within a BTL. This required me to find different ways to direct which PML protocol to use. In addition, it is assume that a BTL either supports RDMA or not. There is no idea of supporting based on the type of buffer one is sending. Therefore, to leverage much of the existing datatype and PML support, I had to make changes in there. Overall, I agree it is not ideal, but the best I could come up with. >-Original Message- >From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of George >Bosilca >Sent: Friday, August 23, 2013 7:36 AM >To: Open MPI Developers >Subject: Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r29055 - in >trunk/ompi/mca: btl btl/smcuda common/cuda pml/ob1 > >Rolf, > >On Aug 22, 2013, at 19:24 , Rolf vandeVaart wrote: > >> Hi George: >> >> The reason it tainted the PML is because the CUDA IPC support makes use >of the large message RDMA protocol of the PML layer. The smcuda btl starts >up, but does not initially support any large message RDMA (RGET,RPUT) >protocols. Then when a GPU buffer is first accessed, the smcuda btl starts an >exchange of some control messages with its peer. If they determine that >they can support CUDA IPC, then the smcuda calls up into the PML layer and >says it is OK to start using the large message RDMA. This all happens in code >that is only compiled in if the user asks for CUDA-aware support. > >The issue is not that is compiled in only when CUDA support is enabled. The >problem is that it is a breakage of the separation between PML and BTL. >Almost all BTL did manage to implement highly optimized protocols under this >design without having to taint the PML. Very similarly to CUDA I can cite CMA >and KNEM support in the SM BTL. So I really wonder why the CUDA support is >so different, at the point where it had to go all over the place (convertor, >memory pool and PML)? > >> The key requirement was I wanted to dynamically add the support for CUDA >IPC when the user first started accessing GPU buffers rather than during >MPI_Init. > >Moving from BTL flags to endpoint based flags is indeed a good thing. This is >something that should be done everywhere in the PML code, as it will allow >the BTL to support different behaviors based on the peer. > >George. > >> This the best way I could figure out how to accomplish this but I am open to >other ideas. > > > >> >> Thanks, >> Rolf >> >>> -Original Message- >>> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of George >>> Bosilca >>> Sent: Thursday, August 22, 2013 11:32 AM >>> To: de...@open-mpi.org >>> Subject: Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r29055 - in >>> trunk/ompi/mca: btl btl/smcuda common/cuda pml/ob1 >>> >>> I'm not very keen of seeing BTL modification tainting the PML. I >>> would have expected support for IPC between GPU must be a BTL-level >>> decision, no a special path in the PML. >>> >>> Is there a reason IPC support cannot be hidden down in the SMCUDA BTL? >>> >>> Thanks, >>> George. >>> >>> On Aug 21, 2013, at 23:00 , svn-commit-mai...@open-mpi.org wrote: >>> Author: rolfv (Rolf Vandevaart) Date: 2013-08-21 17:00:09 EDT (Wed, 21 Aug 2013) New Revision: 29055 URL: https://svn.open-mpi.org/trac/ompi/changeset/29055 Log: Fix support in smcuda btl so it does not blow up when there is no CUDA IPC >>> support between two GPUs. Also make it so CUDA IPC support is added >>> dynamically. Fixes ticket 3531. Added: trunk/ompi/mca/btl/smcuda/README Text files modified: trunk/ompi/mca/btl/btl.h | 2 trunk/ompi/mca/btl/smcuda/README | 113 >>> ++ trunk/ompi/mca/btl/smcuda/btl_smcuda.c | 104 >>> trunk/ompi/mca/btl/smcuda/btl_smcuda.h |28 + trunk/ompi/mca/btl/smcuda/btl_smcuda_component.c | 200 >>> +++ trunk/ompi/mca/btl/smcuda/btl_smcuda_endpoint.h | 5 + trunk/ompi/mca/common/cuda/common_cuda.c |29 + trunk/ompi/mca/common/cuda/common_cuda.h | 3 trunk/ompi/mca/pml/ob1/pml_ob1.c |11 ++ trunk/ompi/mca/pml/ob1/pml_ob1_cuda.c|42 +++
Re: [OMPI devel] [OMPI svn] svn:open-mpi r29060 - in branches/v1.7: . ompi/mca/btl ompi/mca/btl/openib ompi/mca/btl/openib/connect ompi/mca/common/verbs
As Jeff said in his commit message for r29059:
>> Turns out that AC_CHECK_DECLS is one of the "new style" Autoconf
>> macros that #defines the output to be 0 or 1 (vs. #define'ing or
>> #undef'ing it). So don't check for "#if defined(..."; just check for
>> "#if ...".
On Aug 23, 2013, at 8:10 AM, "Steve Wise" wrote:
> Why is the 1.7 changeset different from the trunk changeset? Specifically,
>
> #if defined(HAVE_IBV_LINK_LAYER_ETHERENET)
>
> Is changed to
>
> #if HAVE_DECL_IBV_LINK_LAYER_ETHERNET
>
> Instead of
>
> #if defined(HAVE_DECL_IBV_LINK_LAYER_ETHERNET)
>
>
>
>> -Original Message-
>> From: svn [mailto:svn-boun...@open-mpi.org] On Behalf Of
>> svn-commit-mai...@open-mpi.org
>> Sent: Thursday, August 22, 2013 1:25 PM
>> To: s...@open-mpi.org
>> Subject: [OMPI svn] svn:open-mpi r29060 - in branches/v1.7: . ompi/mca/btl
>> ompi/mca/btl/openib
>> ompi/mca/btl/openib/connect ompi/mca/common/verbs
>>
>> Author: rhc (Ralph Castain)
>> Date: 2013-08-22 14:24:55 EDT (Thu, 22 Aug 2013)
>> New Revision: 29060
>> URL: https://svn.open-mpi.org/trac/ompi/changeset/29060
>>
>> Log:
>> Fixes #3730: Move r29053 to v1.7 branch (Use the
>> HAVE_DECL_IBV_LINK_LAYER_ETHERNET macro.)
>>
>> ---svn-pre-commit-ignore-below---
>>
>> r29053 [[BR]]
>> Use the HAVE_DECL_IBV_LINK_LAYER_ETHERNET macro.
>>
>> Commit r27211 added ifdef checks for #define
>> HAVE_IBV_LINK_LAYER_ETHERNET, which is incorrect. The correct #define
>> is HAVE_DECL_IBV_LINK_LAYER_ETHERNET. This broke OMPI over iWARP.
>>
>> This fixes #3726 and should be added to cmr:v1.7.3:reviewer=jsquyres
>>
>>
>> r29059 [[BR]]
>> Refs #3730
>>
>> Turns out that AC_CHECK_DECLS is one of the "new style" Autoconf
>> macros that #defines the output to be 0 or 1 (vs. #define'ing or
>> #undef'ing it). So don't check for "#if defined(..."; just check for
>> "#if ...".
>>
>> Properties modified:
>> branches/v1.7/ (props changed)
>> branches/v1.7/ompi/mca/btl/ (props changed)
>> Text files modified:
>> branches/v1.7/ompi/mca/btl/openib/btl_openib.c |
>> 2 +-
>> branches/v1.7/ompi/mca/btl/openib/btl_openib_component.c|
>> 2 +-
>> branches/v1.7/ompi/mca/btl/openib/connect/btl_openib_connect_oob.c |
>> 2 +-
>> branches/v1.7/ompi/mca/btl/openib/connect/btl_openib_connect_udcm.c |
>> 2 +-
>> branches/v1.7/ompi/mca/common/verbs/common_verbs_find_ports.c |
>> 4 ++--
>> 5 files changed, 6 insertions(+), 6 deletions(-)
>>
>> Modified: branches/v1.7/ompi/mca/btl/openib/btl_openib.c
>> ==
>> --- branches/v1.7/ompi/mca/btl/openib/btl_openib.c Thu Aug 22 13:44:20
>> 2013(r29059)
>> +++ branches/v1.7/ompi/mca/btl/openib/btl_openib.c 2013-08-22 14:24:55 EDT
>> (Thu, 22 Aug 2013)
>> (r29060)
>> @@ -447,7 +447,7 @@
>> #ifdef HAVE_STRUCT_IBV_DEVICE_TRANSPORT_TYPE
>> switch(openib_btl->device->ib_dev->transport_type) {
>> case IBV_TRANSPORT_IB:
>> -#if defined(HAVE_IBV_LINK_LAYER_ETHERNET)
>> +#if HAVE_DECL_IBV_LINK_LAYER_ETHERNET
>> switch(openib_btl->ib_port_attr.link_layer) {
>> case IBV_LINK_LAYER_ETHERNET:
>> return MCA_BTL_OPENIB_TRANSPORT_RDMAOE;
>>
>> Modified: branches/v1.7/ompi/mca/btl/openib/btl_openib_component.c
>> ==
>> --- branches/v1.7/ompi/mca/btl/openib/btl_openib_component.c Thu Aug 22
>> 13:44:20 2013
>> (r29059)
>> +++ branches/v1.7/ompi/mca/btl/openib/btl_openib_component.c 2013-08-22
>> 14:24:55 EDT (Thu,
>> 22 Aug 2013) (r29060)
>> @@ -719,7 +719,7 @@
>> return OMPI_ERR_NOT_FOUND;
>> }
>>
>> -#if defined(HAVE_IBV_LINK_LAYER_ETHERNET)
>> +#if HAVE_DECL_IBV_LINK_LAYER_ETHERNET
>> if (IBV_LINK_LAYER_ETHERNET == ib_port_attr->link_layer) {
>> subnet_id = mca_btl_openib_get_ip_subnet_id(device->ib_dev,
>>port_num);
>>
>> Modified: branches/v1.7/ompi/mca/btl/openib/connect/btl_openib_connect_oob.c
>> ==
>> --- branches/v1.7/ompi/mca/btl/openib/connect/btl_openib_connect_oob.c
>> Thu Aug 22 13:44:20
>> 2013 (r29059)
>> +++ branches/v1.7/ompi/mca/btl/openib/connect/btl_openib_connect_oob.c
>> 2013-08-22 14:24:55
>> EDT (Thu, 22 Aug 2013) (r29060)
>> @@ -127,7 +127,7 @@
>>IB (this CPC will not work with iWarp). If we do not have the
>>transport_type member, then we must be < OFED v1.2, and
>>therefore we must be IB. */
>> -#if defined(HAVE_STRUCT_IBV_DEVICE_TRANSPORT_TYPE) &&
>> defined(HAVE_IBV_LINK_LAYER_ETHERNET)
>> +#if defined(HAVE_STRUCT_IBV_DEVICE_TRANSPORT_TYPE) &&
>> HAVE_DECL_IBV_LINK_LAYER_ETHERNET
>> if (BTL_OPENIB_CONNECT_BASE_CHECK_IF_NOT_IB(btl)) {
>> opal_output_verbose(5, omp
Re: [OMPI devel] [OMPI svn] svn:open-mpi r29060 - in branches/v1.7: . ompi/mca/btl ompi/mca/btl/openib ompi/mca/btl/openib/connect ompi/mca/common/verbs
Why is the 1.7 changeset different from the trunk changeset? Specifically,
#if defined(HAVE_IBV_LINK_LAYER_ETHERENET)
Is changed to
#if HAVE_DECL_IBV_LINK_LAYER_ETHERNET
Instead of
#if defined(HAVE_DECL_IBV_LINK_LAYER_ETHERNET)
> -Original Message-
> From: svn [mailto:svn-boun...@open-mpi.org] On Behalf Of
> svn-commit-mai...@open-mpi.org
> Sent: Thursday, August 22, 2013 1:25 PM
> To: s...@open-mpi.org
> Subject: [OMPI svn] svn:open-mpi r29060 - in branches/v1.7: . ompi/mca/btl
> ompi/mca/btl/openib
> ompi/mca/btl/openib/connect ompi/mca/common/verbs
>
> Author: rhc (Ralph Castain)
> Date: 2013-08-22 14:24:55 EDT (Thu, 22 Aug 2013)
> New Revision: 29060
> URL: https://svn.open-mpi.org/trac/ompi/changeset/29060
>
> Log:
> Fixes #3730: Move r29053 to v1.7 branch (Use the
> HAVE_DECL_IBV_LINK_LAYER_ETHERNET macro.)
>
> ---svn-pre-commit-ignore-below---
>
> r29053 [[BR]]
> Use the HAVE_DECL_IBV_LINK_LAYER_ETHERNET macro.
>
> Commit r27211 added ifdef checks for #define
> HAVE_IBV_LINK_LAYER_ETHERNET, which is incorrect. The correct #define
> is HAVE_DECL_IBV_LINK_LAYER_ETHERNET. This broke OMPI over iWARP.
>
> This fixes #3726 and should be added to cmr:v1.7.3:reviewer=jsquyres
>
>
> r29059 [[BR]]
> Refs #3730
>
> Turns out that AC_CHECK_DECLS is one of the "new style" Autoconf
> macros that #defines the output to be 0 or 1 (vs. #define'ing or
> #undef'ing it). So don't check for "#if defined(..."; just check for
> "#if ...".
>
> Properties modified:
>branches/v1.7/ (props changed)
>branches/v1.7/ompi/mca/btl/ (props changed)
> Text files modified:
>branches/v1.7/ompi/mca/btl/openib/btl_openib.c |
> 2 +-
>branches/v1.7/ompi/mca/btl/openib/btl_openib_component.c|
> 2 +-
>branches/v1.7/ompi/mca/btl/openib/connect/btl_openib_connect_oob.c |
> 2 +-
>branches/v1.7/ompi/mca/btl/openib/connect/btl_openib_connect_udcm.c |
> 2 +-
>branches/v1.7/ompi/mca/common/verbs/common_verbs_find_ports.c |
> 4 ++--
>5 files changed, 6 insertions(+), 6 deletions(-)
>
> Modified: branches/v1.7/ompi/mca/btl/openib/btl_openib.c
> ==
> --- branches/v1.7/ompi/mca/btl/openib/btl_openib.cThu Aug 22 13:44:20
> 2013(r29059)
> +++ branches/v1.7/ompi/mca/btl/openib/btl_openib.c2013-08-22 14:24:55 EDT
> (Thu, 22 Aug 2013)
> (r29060)
> @@ -447,7 +447,7 @@
> #ifdef HAVE_STRUCT_IBV_DEVICE_TRANSPORT_TYPE
> switch(openib_btl->device->ib_dev->transport_type) {
> case IBV_TRANSPORT_IB:
> -#if defined(HAVE_IBV_LINK_LAYER_ETHERNET)
> +#if HAVE_DECL_IBV_LINK_LAYER_ETHERNET
> switch(openib_btl->ib_port_attr.link_layer) {
> case IBV_LINK_LAYER_ETHERNET:
> return MCA_BTL_OPENIB_TRANSPORT_RDMAOE;
>
> Modified: branches/v1.7/ompi/mca/btl/openib/btl_openib_component.c
> ==
> --- branches/v1.7/ompi/mca/btl/openib/btl_openib_component.c Thu Aug 22
> 13:44:20 2013
> (r29059)
> +++ branches/v1.7/ompi/mca/btl/openib/btl_openib_component.c 2013-08-22
> 14:24:55 EDT (Thu,
> 22 Aug 2013) (r29060)
> @@ -719,7 +719,7 @@
> return OMPI_ERR_NOT_FOUND;
> }
>
> -#if defined(HAVE_IBV_LINK_LAYER_ETHERNET)
> +#if HAVE_DECL_IBV_LINK_LAYER_ETHERNET
> if (IBV_LINK_LAYER_ETHERNET == ib_port_attr->link_layer) {
> subnet_id = mca_btl_openib_get_ip_subnet_id(device->ib_dev,
> port_num);
>
> Modified: branches/v1.7/ompi/mca/btl/openib/connect/btl_openib_connect_oob.c
> ==
> --- branches/v1.7/ompi/mca/btl/openib/connect/btl_openib_connect_oob.c
> Thu Aug 22 13:44:20
> 2013 (r29059)
> +++ branches/v1.7/ompi/mca/btl/openib/connect/btl_openib_connect_oob.c
> 2013-08-22 14:24:55
> EDT (Thu, 22 Aug 2013)(r29060)
> @@ -127,7 +127,7 @@
> IB (this CPC will not work with iWarp). If we do not have the
> transport_type member, then we must be < OFED v1.2, and
> therefore we must be IB. */
> -#if defined(HAVE_STRUCT_IBV_DEVICE_TRANSPORT_TYPE) &&
> defined(HAVE_IBV_LINK_LAYER_ETHERNET)
> +#if defined(HAVE_STRUCT_IBV_DEVICE_TRANSPORT_TYPE) &&
> HAVE_DECL_IBV_LINK_LAYER_ETHERNET
> if (BTL_OPENIB_CONNECT_BASE_CHECK_IF_NOT_IB(btl)) {
> opal_output_verbose(5, ompi_btl_base_framework.framework_output,
> "openib BTL: oob CPC only supported on
> InfiniBand; skipped on
%s:%d",
>
> Modified: branches/v1.7/ompi/mca/btl/openib/connect/btl_openib_connect_udcm.c
> ==
> --- branches/v1.7/ompi/mca/btl/openib/connect/btl_openib_connect_udcm.c
> Thu Aug 22 13:44:20
> 2013 (r2905
Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r29055 - in trunk/ompi/mca: btl btl/smcuda common/cuda pml/ob1
Rolf, On Aug 22, 2013, at 19:24 , Rolf vandeVaart wrote: > Hi George: > > The reason it tainted the PML is because the CUDA IPC support makes use of > the large message RDMA protocol of the PML layer. The smcuda btl starts up, > but does not initially support any large message RDMA (RGET,RPUT) protocols. > Then when a GPU buffer is first accessed, the smcuda btl starts an exchange > of some control messages with its peer. If they determine that they can > support CUDA IPC, then the smcuda calls up into the PML layer and says it is > OK to start using the large message RDMA. This all happens in code that is > only compiled in if the user asks for CUDA-aware support. The issue is not that is compiled in only when CUDA support is enabled. The problem is that it is a breakage of the separation between PML and BTL. Almost all BTL did manage to implement highly optimized protocols under this design without having to taint the PML. Very similarly to CUDA I can cite CMA and KNEM support in the SM BTL. So I really wonder why the CUDA support is so different, at the point where it had to go all over the place (convertor, memory pool and PML)? > The key requirement was I wanted to dynamically add the support for CUDA IPC > when the user first started accessing GPU buffers rather than during MPI_Init. Moving from BTL flags to endpoint based flags is indeed a good thing. This is something that should be done everywhere in the PML code, as it will allow the BTL to support different behaviors based on the peer. George. > This the best way I could figure out how to accomplish this but I am open to > other ideas. > > Thanks, > Rolf > >> -Original Message- >> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of George >> Bosilca >> Sent: Thursday, August 22, 2013 11:32 AM >> To: de...@open-mpi.org >> Subject: Re: [OMPI devel] [OMPI svn-full] svn:open-mpi r29055 - in >> trunk/ompi/mca: btl btl/smcuda common/cuda pml/ob1 >> >> I'm not very keen of seeing BTL modification tainting the PML. I would have >> expected support for IPC between GPU must be a BTL-level decision, no a >> special path in the PML. >> >> Is there a reason IPC support cannot be hidden down in the SMCUDA BTL? >> >> Thanks, >> George. >> >> On Aug 21, 2013, at 23:00 , svn-commit-mai...@open-mpi.org wrote: >> >>> Author: rolfv (Rolf Vandevaart) >>> Date: 2013-08-21 17:00:09 EDT (Wed, 21 Aug 2013) New Revision: 29055 >>> URL: https://svn.open-mpi.org/trac/ompi/changeset/29055 >>> >>> Log: >>> Fix support in smcuda btl so it does not blow up when there is no CUDA IPC >> support between two GPUs. Also make it so CUDA IPC support is added >> dynamically. >>> Fixes ticket 3531. >>> >>> Added: >>> trunk/ompi/mca/btl/smcuda/README >>> Text files modified: >>> trunk/ompi/mca/btl/btl.h | 2 >>> trunk/ompi/mca/btl/smcuda/README | 113 >> ++ >>> trunk/ompi/mca/btl/smcuda/btl_smcuda.c | 104 >> >>> trunk/ompi/mca/btl/smcuda/btl_smcuda.h |28 + >>> trunk/ompi/mca/btl/smcuda/btl_smcuda_component.c | 200 >> +++ >>> trunk/ompi/mca/btl/smcuda/btl_smcuda_endpoint.h | 5 + >>> trunk/ompi/mca/common/cuda/common_cuda.c |29 + >>> trunk/ompi/mca/common/cuda/common_cuda.h | 3 >>> trunk/ompi/mca/pml/ob1/pml_ob1.c |11 ++ >>> trunk/ompi/mca/pml/ob1/pml_ob1_cuda.c|42 >>> trunk/ompi/mca/pml/ob1/pml_ob1_recvreq.c | 6 >>> 11 files changed, 535 insertions(+), 8 deletions(-) >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > --- > 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 list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Detailed documentation on OpenMPI
Some questions are easier than others … On Aug 23, 2013, at 07:54 , mahesh wrote: > I know that its a huge code base. But, I am looking for specific answers like > does OpenMPI use sockets? When Open MPI is using TCP it does indeed use sockets. > Can programs written without mpi libraries be run on > clusters using orte(with some changes)? Yes, that's why you can run "mpirun -np 4 hostname". > It would be really helpful if at least these and related doubts can be solved. Hope that helps. George. > > Thanks, > Mahesh > > On Aug 22, 2013 (jsquyres) wrote >> Note that according to http://www.ohloh.net/p/openmpi, OMPI is over 3/4M >> lines of code. I doubt you will be able to get a thorough understanding of >> *all* of OMPI in a semester or two -- indeed, I doubt that any one Open MPI >> core developer has a thorough understanding of the whole code base (I know I >> don't!). >> >> I don't say these things to discourage you; I actually just want to >> encourage you to set realistic expectations for what you'll be able to do. >> >> Are there any particular areas that you'd like to focus on? MPI -- and the >> Open MPI implementation -- covers a *lot* of different subsystems and >> concepts. >> >> >> On Aug 22, 2013, at 8:06 AM, mahesh wrote: >> >>> Hi, >>> I am an newbie to all MPI concepts and I would like to understand the >>> MPI source code thoroughly for >>> an academic project. So, what I need is an detailed explanation of how >>> every framework and module >>> works. It would be really helpful if wise people could point me to >>> right direction. >>> >>> Thanks, >>> Mahesh >>> ___ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Detailed documentation on OpenMPI
I know that its a huge code base. But, I am looking for specific answers like does OpenMPI use sockets? Can programs written without mpi libraries be run on clusters using orte(with some changes)? It would be really helpful if atleast these and related doubts can be solved. Thanks, Mahesh On Aug 22, 2013 (jsquyres) wrote > Note that according to http://www.ohloh.net/p/openmpi, OMPI is over 3/4M > lines of code. I doubt you will be able to get a thorough understanding of > *all* of OMPI in a semester or two -- indeed, I doubt that any one Open MPI > core developer has a thorough understanding of the whole code base (I know I > don't!). > > I don't say these things to discourage you; I actually just want to encourage > you to set realistic expectations for what you'll be able to do. > > Are there any particular areas that you'd like to focus on? MPI -- and the > Open MPI implementation -- covers a *lot* of different subsystems and > concepts. > > > On Aug 22, 2013, at 8:06 AM, mahesh wrote: > > > Hi, > > I am an newbie to all MPI concepts and I would like to understand the > > MPI source code thoroughly for > > an academic project. So, what I need is an detailed explanation of how > > every framework and module > > works. It would be really helpful if wise people could point me to > > right direction. > > > > Thanks, > > Mahesh > > ___ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/
