On 8/29/2016 7:34 PM, Jason Gunthorpe wrote:
On Mon, Aug 29, 2016 at 03:07:48PM +0300, Yishai Hadas wrote:
They are not self-contained. They have all sorts of inter-dependencies
between each other and the kernel.
The dependencies are around the interfaces with the kernel and with
applications, not in other parts. Using the extension mechanism a
provider can extend both APIs without breaking other.
Going forward do not expect the
distros to just blindly take whatever tar ball you publish into their
stable releases. That was special situation for the 'Technology
Preview' stage in RHEL6.
No distro expects to take blindly and if it does it's bad.
AFAIK, there are testing and other actions done in in both distros and
providers sides to make sure that any package is ready for a release.
Remember, most of the code is dead, the maintainer is MIA or hasn't
accepted a patch in months or years.
Agree, that's why I think that such dead providers code shouldn't be put
and maintained with live providers, it doesn't make sense.
How many providers/libraries in this GIT are really active ?
mlx4/mlx5 is an notable exeption. You and Doug should work out a
reasonable appraoch. Maybe he takes your pulls directly, maybe you
have co-commit access on Github (the team approach), something else?
We definitely need to close this point before going a head into any
solution that might block a fast progress of accepting/merging new code
of live/maintained projects as of libmlx4/5.
This is already basically the case, you need to wait for Doug to take
any libibverbs changes before you can push any provider feature
change.
We should definitely find a way to escalate the review/acceptance of new
features in libibverbs, need to take it with Doug as well.
This is incorrect, when Doug is taking into libibverbs, vendor code that is
ready can be taken immediately, the new approach might cause some extra
delays and slowness.
I haven't seen you do that.
What are you talking about ? see last feature of TSO as an example, it
was published in the list for both libibverbs and libmlx5, when Doug
accepted the libiberbs part just an hour later I merged the libmlx5 part
into its formal GIT at openfabrics and noted on that in the list.
Same was done for other features as of timestamping, rereg_mr, etc.
We must save this ability before going forward here.
If you are pushing code into your provider that doesn't work with
upstream libibverbs then you will be blacklisted by the distros. Do
not do that.
Sure that we take *only* code that works with upstream libibverbs. Both
libmlx4 and libmlx5 are *always* in a ready state for a release with
latest libibverbs.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
