[ofa-general] Re: [ewg] RFC: Do we wish to take MPI out of OFED?

[Jeff Squyres]

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