On Jun 9, 2009, at 6:49 AM, Pavel Shamis (Pasha) wrote:
The excluding of MPI from OFED, will only push users to use vendor
specific OFED builds (that provides MPI out of box) and I'm not sure
that it is good for OFED community.
Pasha and I discussed exactly this point in IM and we agreed to
disagree. :-) FWIW, I think this point touches on an issue that is
deeper than just MPI in OFED. Different vendors having their own
[potentially incompatible] versions of OFED -- each with different
value-add -- is both good and bad.
GOOD: vendors can innovate and differentiate
BAD: it seems like the bad old days of different/incompatible vendor
versions of mVAPI: <vendorX> OFED != <vendorY> OFED != <community> OFED
I've heard similar stories from many users, "I have <vendorX> OFED --
is that the same/compatible as <vendorY/community> OFED?" And
sometimes the answer is "not entirely".
Yow! We need a technology/system/process/whatever for allowing
vendors to distribute what they need without effectively forking OFED
to make their own "<vendorX> OFED". Even if <vendorX> OFED *should*
be the same as community OFED, it sometimes (?usually?) is different
in very subtle/small-but-important ways (e.g., vendorX compiling/
installing vendorY's drivers, but not QA'ing them). To be clear: with
each vendor putting out their own different versions of OFED, it makes
for big user confusion about compatibility and ecosystem.
Note that Pasha's answer at least somewhat implies that he feels the
same way. :-)
--
Jeff Squyres
Cisco Systems
_______________________________________________
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
