On 5/4/2017 1:34 PM, Hefty, Sean wrote:
>> This is exactly why we so strongly discourage this out of tree
>> stuff - getting something unmergable in OFED is *NOT* Job Done,
>> Time to Go Home. Down this path just creates another Lustre mess.
>
> Actually, this may be 'job done'. No individual or company is
> obligated to provide upstream software for any of their hardware.
Very true, but in that case you would expect Intel to be shipping the
software, not OFA. Much like they already do with their compiler, their
MPI, etc.
> OFA decides what to ship in their software products, not the greater
> linux kernel community. Individual companies can decide if out of
> tree maintenance is more cost effective than trying to merge code
> upstream. Because that's what this ultimately comes down to.
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.
> IMO, the only people who have legitimate complaints here are those
> people running Xeon Phi with Mellanox HCAs who are being forced to
> use OFED, rather than upstream code.
I suspect there are legitimate grounds to complain about the fact that
it is shipped in the OFA OFED and not limited to an Intel OFED
derivative similar to Mellanox OFED.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG Key ID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
Attachment:
signature.asc
Description: OpenPGP digital signature
