[Ofa_boardplus] OFED releases

[Woodruff, Robert J]

Jason wrote,
>Bear in mind that, except in some limited cases, OFA members are already solving these problems, using the industry accepted 'upstream first' >collaborative process.

>1) The upstream kernel is immediately available for pre-release
  > testing of new features
>2) The single kernel provides vendor co-existence and the
>   collaborative testing encourages interoperability.

I have to disagree with this somewhat. Getting your code upstream does allow it to be in the same kernel as someone else's driver,
but it does not at all guarantee interoperability. The reason is that most vendors only develop and test their code with their H/W and 
do not always test to make sure it will interoperate with or even coexist with a driver and hardware from another vendor. 
In most cases, they do not even have any of the other vendor's hardware. That is why things like the IBTA interop events
and OFA logo events are so valuable. They allow vendors to test their code and hardware in a lab that has everyone's hardware and
vendors regularly find bugs that they need to fix, and in many cases the bugs are in code that is already upstream. 

> 1) Users need a mechanism to use features/capabilities that have not landed in upstream yet.

Unfortunately the sad fact is that it takes at least 6-12 months to get code into a production Linux distro like RHEL and SLES even after it 
is accepted upstream.
So even if the code can get upstream quickly, it will take another 6-12 months before customers that want/need to run a
Distro kernel can use it. This is why vendors regularly provide code that can be added into an existing released distro kernel for their
latest hardware until the code has gone upstream and then picked up by a Linux distro. 

Also, the distro's typically only release that new driver in their latest distro release version and not any older one.  Some customers 
want/need to deploy an older version of RHEL and SLES. Thus there is another need for having a distribution of code that customers can
overlay onto an older distro kernel.

These are some of the benefits of the community OFED, i.e., to have a package that can be built and run on various older distro kernels
and since OFED is used in the OFA logo interop testing, people know that the interoperability testing has been done. 


-----Original Message-----
From: Ofa_boardplus [mailto:ofa_boardplus-bounces at lists.openfabrics.org] On Behalf Of Jason Gunthorpe
Sent: Thursday, May 11, 2017 12:36 PM
To: Atchley, Scott <atchleyes at ornl.gov>
Cc: ofa_boardplus at lists.openfabrics.org
Subject: Re: [Ofa_boardplus] OFED releases

On Thu, May 11, 2017 at 06:18:38PM +0000, Atchley, Scott wrote:
> Hi all,
> 
> To be clear, I was asking for two things:
> 
> 1) Users need a mechanism to use features/capabilities that have not 
> landed in upstream yet
>
> 2) Interoperability

Bear in mind that, except in some limited cases, OFA members are already solving these problems, using the industry accepted 'upstream first' collaborative process.

1) The upstream kernel is immedaitely available for pre-release
   testing of new features
2) The single kernel provides vendor co-existance and the
   collaborative testing encourages interoperability.

The way I read your email is that you think the process is too slow for your use case?

Jason
_______________________________________________
Ofa_boardplus mailing list
Ofa_boardplus at lists.openfabrics.org
http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus