[ewg] [ANNOUNCE] OFED 4.8-rc2 release is available

[Doug Ledford]

On 5/4/2017 3:14 PM, Woodruff, Robert J wrote:
> Doug Ledford wrote,
>> The OFA has already learned their lesson once with XRC.  I wonder
>> if they are getting ready to get hit with another lesson over this.
>> The issue is if the OFA ships an API and it isn't upstream, then
>> that API needs to legitimately be a >private, should never conflict
>> with upstream API.  If upstream then implements the same thing in a
>> different way and users are exposed to the rather unpleasant choice
>> of code to OFA's API or to upstream's API for the same thing, it
>> >creates a schism in the user's code base around what API to
>> use/support.  This is entirely contrary to the OFA's stated goals
>> about the end user experience of people using their RDMA software.
>> So Intel can certainly make any cost >analysis they want about
>> their hardware and the software to support it, but the OFA is not
>> Intel's personal software distributor and the OFA must look at
>> other, bigger picture issues than Intel.
> 
> The Xeon-Phi code is somewhat different than what happened in the
> past with XRC.  In the case of XRC, it was integrated into the base
> OFED package and built-in by default. For the Xeon-Phi code, it is
> clearly marked as a technology preview and is not even compiled in at
> all unless specifically enabled. This is not too terribly different
> than the experimental branches that the kernel has. Also, the
> Xeon-Phi code does not add any new APIs.

It implements a new kernel internal API, yes?

> It simply implements a
> driver set and library, thus there is no risk in someone coding to an
> API in OFED that gets totally changed once it gets upstream.

I'm not sure I understand your statement here Woody.  If there's no API,
then how do people even use the hardware?  Or are you saying that the
API is in the library, and that API can be preserved even if the
underlying driver implementation is changed to match whatever upstream
might implement instead of what you already have implemented?

> you really do not have a say in the matter.

Nope.  I don't.  But, as I pointed out in my other email, if
relationships matter, then whether or not someone has a say does not
negate the need to listen.

Personally, I haven't really investigated this code so I'm not going to
argue against the fact that the OFA ships it, other than what I have
already which is that it has been a stated goal of the OFA to foster a
unified code base, so collaborating with upstream is generally
necessary.  If you are saying that the Xeon Phi support is implemented
in a library (like nVidia's CUDA support) that insulates the end user
from a possible fracture if upstream implements things differently, then
that mostly settles my concerns.  I still think it would be best if the
Xeon Phi people collaborated with upstream on the kernel internal Peer
to Peer PCI API as that's evidently a requirement of the Xeon Phi
library?  It is conceivably possible failure to collaborate could in
fact break the Xeon Phi library if they simply don't implement something
the library has a hard requirement on.  But that's outside of my
particular wheel house so I'm just suggesting that it might be a wise
thing to do.

-- 
Doug Ledford <dledford at redhat.com>
    GPG Key ID: B826A3330E572FDD
    Key fingerprint = AE6B 1BDA 122B 23B4 265B  1274 B826 A333 0E57 2FDD

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20170504/8ae3d32c/attachment.sig>