[Ofa_boardplus] OFED releases

Paul Grun grun at cray.com
Tue May 16 10:48:15 PDT 2017


>The only avenue left is a technical solution - someone has to fund the work to
>actually go and create a fork that matches what the sites need, pulling from the
>vendor forks, and do this faster than the upstream process would get it done.

Would it be unreasonable to think of the EWG as being the technical body that could do what Jason suggests?

>-----Original Message-----
>From: Ofa_boardplus [mailto:ofa_boardplus-bounces at lists.openfabrics.org] On
>Behalf Of Jason Gunthorpe
>Sent: Thursday, May 11, 2017 4:05 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 09:44:11PM +0000, Atchley, Scott wrote:
>
>> Again, I am not arguing for a change in anyone’s workflow from pushing
>> upstream first. But while upstream debates implementation and while
>> the eventual design works its way to the distro backports, what should
>> users do with hardware on their floor?
>
>They need to use the fork of the software that vendor provides. There is no other
>answer. Only the vendor is going to be willing to support and develop that forked
>code.
>
>Your #2 problem is the real intractable issue.
>
>The upstream neutral collaborative process is how we have been successful in
>getting the vendors to work together, at all. That has become an industry wide
>defacto agreed upon way to work on a shared code base.
>
>There is no way, politically, to just short circuit that process and keep the vendors
>engaged.
>
>It isn't reasonable to ask the vendors to union their forks of the RDMA stack
>outside of the upstream process - there are overlaps and disagreements, this
>would create a different layer of arguing. As a group, the vendors have no
>incentive to do that.
>
>The only avenue left is a technical solution - someone has to fund the work to
>actually go and create a fork that matches what the sites need, pulling from the
>vendor forks, and do this faster than the upstream process would get it done.
>
>Frankly, this is what all the big cloud operators do internally - they fund a kernel
>and infrastructure development team to mangle the software into the shape they
>want, and upstream things to minimize their maintenance cost.
>
>Jason
>_______________________________________________
>Ofa_boardplus mailing list
>Ofa_boardplus at lists.openfabrics.org
>http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus


More information about the Ofa_boardplus mailing list