I agree with DK from OSU. There are clear advantages to having MPI included with OFED. Not only will it make testing of a complete solution easier by both OFED and MPI suppliers, but it will also improve ease of use for end users. As DK points out there are continual improvements in MPIs which may depend on bug fixes and/or new features in newer versions of OFED. Identifying a known good combination will be important to most end users, etc.
I would point out that the OFED API seems to be holding up quite well. Applications which we built against OFED 1.3 have worked in binary form against OFED 1.4 and 1.4.1 without issue, in fact there are many cases where we build binaries for applications against OFED 1.3 and ship the same binary for use on both old and new OFED versions. However MPI has some differences in this area. In the constant search for better latency and bandwidth, there will be ongoing development and tuning. So in many cases the best performance for MPI will require the latest MPI and the latest OFED. This does not necessarily mean the API is broken, but rather it means a combination has been well tuned and tested. In most if not all cases, other combinations will work well, but may not achieve the same performance level. This is simply the nature of the HPC marketplace. Todd Rimmer Chief Architect QLogic Network Systems Group Voice: 610-233-4852 Fax: 610-233-4777 [email protected] www.QLogic.com > -----Original Message----- > From: [email protected] [mailto:general- > [email protected]] On Behalf Of Dhabaleswar Panda > Sent: Thursday, June 04, 2009 2:02 PM > To: Tziporet Koren > Cc: EWG; OpenFabrics General > Subject: [ofa-general] Re: [ewg] RFC: Do we wish to take MPI out of > OFED? > > Tziporet, > > >Main reasons to keep MPI in OFED: > >- All participants test with the same MPI versions, and when > installing > >OFED it is ensured that MPI will work fine with this version. > >- Customers convenience in install (no need to go to more sites to get > MPI) > >- MPI is an important RDMA ULP and although it is not developed in OFA > >it is widely used by OFED customers > > I support keeping MPI packages in the OFED because of the above > positive > points you have mentioned. > > I would also like to mention that keeping MPI packages in OFED helps to > test out various new features and functionalities (such as APM and XRC > in > the past and the new memory registration scheme being discussed now) as > they get introduced. Such an integrated approach helps to test out > these > features at the lower layers as well as at the MPI layer. This process > helps to resolve out any bugs with the new features during the testing > process itself. It also accelerates the deployment and use of these new > features in the community. > > However, to make the complete OFED release process work smoothly for > everybody (vendors, distros, users, etc.) without affecting the release > schedule, it is essential that stable MPI packages are added to OFED. > This > is what we have been doing wrt MVAPICH and MVAPICH2 for the last > several > years. > > If the developers of any MPI package do not want it to be a part of the > OFED due to any constraints, it should be allowed. However, such an > action > should not force to remove all MPI packages. > > >From the point of view of MVAPICH and MVAPICH2 packages in OFED, we > have > been providing stable packages to OFED for the last several years > helping > the OFED community and would like to continue with this process. > > Thanks, > > DK > > > > _______________________________________________ > general mailing list > [email protected] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib- > general _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
