<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">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.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">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.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div><div class="gmail_default" style="font-family:times new roman,serif">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.<br><br></div><div class="gmail_default" style="font-family:times new roman,serif">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.</div><div class="gmail_default" style="font-family:times new roman,serif"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 11, 2017 at 1:18 PM, Atchley, Scott <span dir="ltr"><<a href="mailto:atchleyes@ornl.gov" target="_blank">atchleyes@ornl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
To be clear, I was asking for two things:<br>
<br>
1) Users need a mechanism to use features/capabilities that have not landed in upstream yet<br>
<br>
2) Interoperability<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks,<br>
<br>
Scott<br>
______________________________<wbr>_________________<br>
Ofa_boardplus mailing list<br>
<a href="mailto:Ofa_boardplus@lists.openfabrics.org">Ofa_boardplus@lists.<wbr>openfabrics.org</a><br>
<a href="http://lists.openfabrics.org/mailman/listinfo/ofa_boardplus" rel="noreferrer" target="_blank">http://lists.openfabrics.org/<wbr>mailman/listinfo/ofa_boardplus</a><br>
</blockquote></div><br></div>