[Ofa_boardplus] OFED releases

[Christoph Lameter]

It is not useful to use OFED for testing. Upstreaming involves sending
patches upstream while developing the code to get feedback and have a
proper design so that the upstream acceptance can occur. During that time
patches live in git trees that can be pulled from by the maintainer and
others for testing. If the patches survive testing and are deemed ready to
be merged they can be obtained from there. Putting patches into OFED makes
the patches inaccessible for testing for the people involved in linux-rdma
and generally people will be less inclined to merge a patch that has not
been submitted and tested using the regular procedure. Inn general I and
others are very skeptical if we get patches from OFED because they landed
there mostly because they were such a bad design that they could not be
discussed on the mailing lists.

There is no lag with up streaming. Patches can be pulled from the relevant
git archive if they were not merged or from the maintainer tree or from
Linus tree himself. Merge periods occur regularly in 3 month intervals.
Kernel/distros are particular and should not be run for testing. Upstream
kernels can be run on any distro to validate that the patches are
functional and they will not be distro specific. We often test patchsets
that are just a few days old by pulling from the git tree of the author and
rebuilding the kernel.

OFED is a currently problem for upstream acceptance and would be best for
all concerned if it would no longer exist. I cannot test patches from there
without a huge effort and others have the same experience. Patches cannot
be easily applied upstream since they are against an older code base (that
may also contain numerous unacceptable patches) and so I feel its a waste
of effort even to consider these patches earnestly. The development pace
there is glacial and we have experienced bizarre bugs whenever we tried to
run an "OFED" kernel.

The lag exist because of OFED.  It is not a problem upstream. Please lets
get rid of the lag by dropping OFED and follow upstream conventions that
are used by a  lot of other Kernel subsystems.


On Thu, May 11, 2017 at 1:18 PM, Atchley, Scott <atchleyes at ornl.gov> 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
>
> Item 1 is necessary because there is a lag getting things upstream. In the
> meantime, organizations are buying hardware and want to get the most
> benefit from it now. Landing a $200 million machine that is hobbled is not
> ideal. If the model is the vendor upstreams everything and provides patches
> for the items queued, but not landed, fine. I am also fine with a model
> that says that we land it in OFED and use that. The issue for both is
> ensuring that they work correctly with my preferred kernel/distro.
>
> Item 2 is a reality for centers that have lots of hardware from multiple
> vendors. We have machines with Cray networks and IB, Intel networks and IB,
> etc. In these cases, it is probably best to only use the kernel/distro
> in-box code unless it falls under item 1. In that case, we need everyone to
> play nice and stop the finger pointing.
>
> Thanks,
>
> Scott
> _______________________________________________
> Ofa_boardplus mailing list
> Ofa_boardplus at lists.openfabrics.org
> http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/ofa_boardplus/attachments/20170511/679a9dda/attachment.html>