<div dir="ltr"><div class="gmail_default" style="font-family:times new roman,serif">Ok that would be a different model for OFED. Provide git trees against the relevant distro kernels and then build based on that one. Drop the ancient code base approach. This means you would have a tree vs RH 7.3 one vs RH 7.2, one vs SUSE etc etc. Its a bit of busywork because while this is working its also the wrong approach.</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">In that case one should be working closely with the distros to get the patches from upstream into the code so that it goes through Q&A of the linux distro.</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">Again we do not use OFED because we do not need to. We have worked with upstream and Redhat and all our changes are in and are fully Q&Aed in every release cycle by them. You are using a wrong approach that causes lots of busywork that could be eliminated.</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">Distros can even do point releases for you if you have an emergency feature that you want. Its a matter of establishing the proper support relationships and working with upstream..... Not with OFED.</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 Fri, May 12, 2017 at 12:56 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"><span class="">> On May 12, 2017, at 1:10 PM, Christoph Lameter <<a href="mailto:christoph@lameter.com">christoph@lameter.com</a>> wrote:<br>
><br>
> Rejection is something that occurs if you no longer maintain a patchset. Otherwise you would keep the patchset up to date in a git repository and work on it until it is accepted. People who want to use that shiny new feature can use it even though it is not yet merged by pulling from the git repo. That does not mean the patch is rejected.<br>
<br>
</span>This is a possibility and I would not rule it out.<br>
<span class=""><br>
<br>
> You are sabotaging that process by putting the patch into OFED and not maintaining the patchset properly. Such behavior is usuall a reason for the maintainer of a subsystem to conclude that you have no interest in upstreaming your work and thus they will stop showing interest in your work as well.<br>
<br>
</span>I am not sabotaging anything. I will say it again until you acknowledge it - I am not proposing vendors put something in OFED and the distros and/or kernel to pull from OFED. I am saying that I am fine with vendors putting something in OFED that can be distributed as RPMs because many centers require that format and may not accept pulling patches from git repos.<br>
<br>
I repeat - I am not suggesting that kernels and/or distros pull from OFED. I look at OFED as a convenience package for users if they want it. If they do not, then let’s stop.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> Frankly its usually the fault of the submitter or the company that tries to do this since they stop working on it. It is not the community that does it. There may be feedback saying not this way. Then you need to work on the issue.<br>
><br>
><br>
> On Thu, May 11, 2017 at 4:41 PM, Atchley, Scott <<a href="mailto:atchleyes@ornl.gov">atchleyes@ornl.gov</a>> wrote:<br>
> Hi Christoph,<br>
><br>
> Please note that I was not proscribing a solution. I was simply stating my requirements. I have no issues with a vendor-specific release (e.g. MOFED) or a release based on multiple vendors (e.g. OFED) with the proviso that it works with my kernel/distro. I am not requiring that upstream pull from OFED. Do not create straw men.<br>
><br>
> There is a lag with upstreaming. When 10G Ethernet was the new shiny hotness, Myricom innovated some new features that were rejected by the kernel for more than a year (e.g. receive into pages rather than the skbuf). The kernel eventually came around and saw it our way. In the meantime, we shipped an out-of-tree driver supported on multiple distros/kernels and our help desk’s first response to any user was dump the in-kernel driver and install the out-of-tree driver. Another example was MMU notifiers. I think Quadrics went out of business before the kernel finally adopted something useful years after they proposed a solution.<br>
><br>
> Watching the linux-rdma list about adopting new features has examples all the time about designs being rejected. I am not arguing that they should not be rejected, but that adds to the delay of a new feature being adopted. In the meantime, vendors are shipping hardware and their users want a solution even if it is not the most elegant.<br>
><br>
> Scott<br>
><br>
> > On May 11, 2017, at 3:07 PM, Christoph Lameter <<a href="mailto:christoph@lameter.com">christoph@lameter.com</a>> wrote:<br>
> ><br>
> ><br>
> > 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.<br>
> ><br>
> > 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.<br>
> ><br>
> > 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>
> > 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.<br>
> ><br>
> ><br>
> > On Thu, May 11, 2017 at 1:18 PM, Atchley, Scott <<a href="mailto:atchleyes@ornl.gov">atchleyes@ornl.gov</a>> wrote:<br>
> > 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>
> ><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>