On Thu, 2009-06-04 at 14:02 -0400, Dhabaleswar Panda wrote: > 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)
It's interesting that you mention XRC support as something from the past. As far as I'm concerned, it's still a "hasn't landed yet" feature as it still hasn't landed upstream. > 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. Such an "integrated" approach is great for a test lab, but has no place in a production environment. This "integrated" approach is what you do when you are in proof of concept phase. After that, you move into development phase where you engineer it properly, define the API, clean up the code, fix bugs, etc. (this is generally what happens during the linux kernel review process, or at least partially). Finally, you reach a stable phase, where most of the bugs are fixed, the API is fixed, and you can generally rely upon the software to work as expected and to handle the majority of situations it is likely to encounter. This "integrated" approach you mention is really only useful when you are trying to leap frog directly from proof of concept to production use without ever going through the other phases and without ever bringing your code quality up to snuff. > 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 you're just throwing in the latest stable release, then it serves no purpose. Whether it's in OFED or on your site makes absolutely 0 difference except to the size of the OFED tarball. > 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 -- Doug Ledford <dledf...@redhat.com> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband
signature.asc
Description: This is a digitally signed message part
_______________________________________________ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg