[Ofa_boardplus] OFED releases

Fri May 12 10:10:32 PDT 2017

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.

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.

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/20170512/17f54a4d/attachment.html>