[Ofa_boardplus] OFED releases

Mon May 15 09:06:00 PDT 2017

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.

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.

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.

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.

On Fri, May 12, 2017 at 12:56 PM, Atchley, Scott <atchleyes at ornl.gov> wrote:

> > On May 12, 2017, at 1:10 PM, Christoph Lameter <christoph at lameter.com>
> wrote:
> >
> > 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.
>
> This is a possibility and I would not rule it out.
>
>
> > 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.
>
> 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.
>
> 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.
>
>
> > 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.
> >
> >
> > On Thu, May 11, 2017 at 4:41 PM, Atchley, Scott <atchleyes at ornl.gov>
> wrote:
> > Hi Christoph,
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > Scott
> >
> > > On May 11, 2017, at 3:07 PM, Christoph Lameter <christoph at lameter.com>
> wrote:
> > >
> > >
> > > 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/20170515/fb315b46/attachment.html>