RE: [ewg] RFC: Do we wish to take MPI out of OFED?
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 and ease of inclusion for linux distro suppliers. 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. -Original Message- From: ewg-boun...@lists.openfabrics.org [mailto:ewg-boun...@lists.openfabrics.org] On Behalf Of Dhabaleswar Panda Sent: Thursday, June 04, 2009 2:02 PM To: Tziporet Koren Cc: EWG; OpenFabrics General Subject: 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 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] RE: [ewg] RFC: Do we wish to take MPI out of OFED?
A few clarifications are probably worthwhile at this point. 1. No one is suggesting divorcing MPI from the OFED testing/release cycle. It's obviously a Good Thing (and has been stated multiple times on this thread). It is easy to indicate good combos of MPI and OFED in documentation and web pages. However, most users expect the latest MPI implementation versions to work with the latest version of OFED (which is not unreasonable). Looking for compatibility between older MPI/OFED versions is something that is almost always relegated to googling. 2. The distinction between development and release phases seems to have been blurred in this discussion. The development phase is where MPI's collaborate with verbs developers to test new APIs, functionality, etc. OFED is the final product, not the development phase. Hence, I'm not sure that the point of continual improvements in MPI depend on bug fixes/new features in OFED is relevant. 3. As Doug described, packaging MPI and OFED together actually makes it *harder* for distros. Remember that RHEL and SUSE don't end up using any of the OFED packaging; they essentially use the individual SRPMs. On Jun 5, 2009, at 8:37 AM, John Russo wrote: 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 and ease of inclusion for linux distro suppliers. 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. -Original Message- From: ewg-boun...@lists.openfabrics.org [mailto:ewg-boun...@lists.openfabrics.org ] On Behalf Of Dhabaleswar Panda Sent: Thursday, June 04, 2009 2:02 PM To: Tziporet Koren Cc: EWG; OpenFabrics General Subject: 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 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ general mailing list gene...@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general -- Jeff Squyres Cisco Systems ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ofa-general] RE: [ewg] RFC: Do we wish to take MPI out of OFED?
On Fri, Jun 05, 2009 at 09:44:09AM -0400, Jeff Squyres wrote: 3. As Doug described, packaging MPI and OFED together actually makes it *harder* for distros. Remember that RHEL and SUSE don't end up using any of the OFED packaging; they essentially use the individual SRPMs. I would almost say the entire OFED process is making it harder for the distros, and I mean that in a very general sense. A working IB stack has been in the kernel for a long time now. Can I install Fedora Core, Ubuntu, Debian, etc and have all the necessary IB tools and diagostics available? Nope. IMHO, the entire process would be better served if OFA focused on producing a bleeding edge environment within the community distributions (Fedora, Debian, OpenSuse, etc) and testing that entire stack, including MPIs included in the distro. If this had been done from the start I would have a complete IB stack available in every single distribution TODAY. The truth is, within the Linux world, if you want bleeding edge stuff you use something like FC or Debian Unstable. Otherwise you settle for older, hopefully more tested stuff. The OFED distribution ontop of a distribution is just weird and painfull... For selectivly moving an old distro forward I would *much* rather have true backport packages that exactly match in form and function the native packages in my distro with new versions. That is a far safer path if I actually care about not disrupting my core distribution. Jason ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
