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 installingOFED 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 itis widely used by OFED customersAs 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 <[email protected]> Wroclaw Centre for Networking & Supercomputing, HPC DepartmentPolitechnika Wr., pl. Grunwaldzki 9, bud. D2/101, 50-377 Wroclaw, POLANDphone: +48 71 3202043, fax: +48 71 3225797, http://www.wcss.wroc.pl _______________________________________________ ewg mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
-- Doug Ledford <[email protected]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford InfiniBand Specific RPMS http://people.redhat.com/dledford/Infiniband
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
