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

[Doug Ledford]

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  
a consumer of that API.  This is no different than TCP sockets and MPI  
stacks: API provider/consumer relationship.  If there is a problem  
between the MPIs and the RDMA stacks from version to version, it means  
that one of them isn't adhering to the API.  The proper solution to  
that problem is *NOT* to put them together and throw the API out the  
window, it's to get the API provider and consumer to adhere to the API  
and to make sure that the API works.  Otherwise, the only solution is  
to bundle *every* consumer of that API with the API provider because  
the API stability is, you guessed it, craptacular.

If you aren't part of the solution, you're part of the problem.  Don't  
encourage craptacular engineering that throws the API out the window.

>
> thanks, Pawel
> -- 
> Pawel Dziekonski <pawel.dziekonski at wcss.pl>
> Wroclaw Centre for Networking & Supercomputing, HPC Department
> Politechnika Wr., pl. Grunwaldzki 9, bud. D2/101, 50-377 Wroclaw,  
> POLAND
> phone: +48 71 3202043, fax: +48 71 3225797, http://www.wcss.wroc.pl
> _______________________________________________
> 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
http://people.redhat.com/dledford/Infiniband




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