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

[Woodruff, Robert J]

Jeff wrote,

>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.

I see this as a probalem as well. I think that some cases,
the forked OFED stacks are a superset of OFED plus other vendor supplied stuff,
like firmware for their card. If they are however removing support for the 
other IHV's drivers, I see this as a problem. I think that if we split 
all of the common code from the kernel RPM into it's own RPM and each
IHV provide RPMs for their drivers (as I suggested in the last EWG meeting),
that should help this problem as then a vendor supplied release could 
contain exactly the RPMs from OFED and not a derivative that removes support 
for another vendor's hardware. 

my 2 cents.

woody


-----Original Message-----
From: general-bounces at lists.openfabrics.org [mailto:general-bounces at lists.openfabrics.org] On Behalf Of Jeff Squyres
Sent: Thursday, June 11, 2009 4:49 AM
To: Pavel Shamis (Pasha)
Cc: general at lists.openfabrics.org
Subject: Re: [ofa-general] Re: [ewg] RFC: Do we wish to take MPI out of OFED?

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
general at lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general