[ewg] RFC: Do we wish to take MPI out of OFED?

[Doug Ledford]

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 at lists.openfabrics.org
> http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20090606/85a54b51/attachment.sig>