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

[Doug Ledford]

On Wed, 2009-06-03 at 19:14 +0200, Pawel Dziekonski wrote:
> On Wed, 03 Jun 2009 at 10:14:07AM -0400, Doug Ledford wrote:
> > On Jun 3, 2009, at 3:39 AM, Pawel Dziekonski wrote:
> >> On Tue, 02 Jun 2009 at 10:30:07PM +0300, Tziporet Koren wrote:
> >>
> >>> 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
> >>
> >> As a customer I strongly support above mentioned pros. It's a
> >> guarantee for us that MPI is well tested with OFED release.
> >
> > MPI makes an effective test bed for the RDMA stack whether it is shipped 
> > with it or not. Removing the MPIs from the distribution would not, in all 
> > likelihood, change the fact that MPIs would be used to test the RDMA stack 
> > prior to release.
> >
> >> I believe that this effort saves a lot of troubles that would be
> >> raised from separate releases of MPI and OFED distros.
> >
> > If you truly believe this, and you accept that shipping the MPI with
> > the RDMA stack is an acceptable solution to the problem, then you
> > are encouraging totally craptacular engineering as a customer.
> > Since you have a non-US email address, and since craptacular is a
> > word I use frequently, but which I also sort of just made up, let me
> > define that. Sometimes, things are good. When they are really good,
> > they are spectacular. Sometimes, things are crap. When they are
> > *really* crap, they are craptacular.
> >
> > The RDMA stack provides an API. The MPI stacks are nothing more than
> 
> you look at the problem from vendor point of view (vendor-like mail
> domain? ;). you care about api. i care about mpi.

I care about both.  I care about the fact that a solid, well adhered to
API makes for lots of happy MPI campers, not just one happy MPI camper.
And the API road is the path to long term interoperability, not just
short term.  So if you really care about MPI, I would recommend you look
to the long term, and you may find you agree with me then.

> from technical point of view it is enough for me if you say in ofed
> docs that THIS and THAT particular versions of MPI was tested and
> WORKS. just like suppoerted and tested list of linux kernels and linux
> distros. I definitely can download and compile mpi by myself. however
> since you already used some versions of MPI to test the RDMA stack
> prior to release why not simply attach it to release? it just makes
> the release more complete from CUSTOMER point of view.

For the cons that you stripped from the original email: it throws off
one or the other's release schedule, it delays things, etc.

-- 
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/20090604/118384c0/attachment.sig>