From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Ledford Subject: Re: [ewg] [ANNOUNCE] OFED 4.8-rc2 release is available Date: Thu, 4 May 2017 16:14:55 -0400 Message-ID: <867b51f9-ad2f-6e8b-6aa8-b5b8fb119931@redhat.com> References: <590096A3.5090107@dev.mellanox.co.il> <20170427070657.GA13585@infradead.org> <20170504084933.GA1359@infradead.org> <9C6B67F36DCAFC479B1CF6A967258A8C7E953FA6@ORSMSX115.amr.corp.intel.com> <20170504153003.GA854@obsidianresearch.com> <1828884A29C6694DAF28B7E6B8A82373AB1199FA@ORSMSX109.amr.corp.intel.com> <75ebb17e-cec3-6605-2a2f-d2533e95a5ec@redhat.com> <9C6B67F36DCAFC479B1CF6A967258A8C7E95451A@ORSMSX115.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hKJEBndTvCcMXpUErWF2gw6gMeA17bNNn" Return-path: In-Reply-To: <9C6B67F36DCAFC479B1CF6A967258A8C7E95451A-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "Woodruff, Robert J" , "Hefty, Sean" , Jason Gunthorpe Cc: Christoph Hellwig , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org" List-Id: linux-rdma@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hKJEBndTvCcMXpUErWF2gw6gMeA17bNNn Content-Type: multipart/mixed; boundary="8TJjCfwuE85JgbLqCuBGcxRvSti0xqIw4"; protected-headers="v1" From: Doug Ledford To: "Woodruff, Robert J" , "Hefty, Sean" , Jason Gunthorpe Cc: Christoph Hellwig , "linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "ewg-ZwoEplunGu1OwGhvXhtEPSCwEArCW2h5@public.gmane.org" Message-ID: <867b51f9-ad2f-6e8b-6aa8-b5b8fb119931-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Subject: Re: [ewg] [ANNOUNCE] OFED 4.8-rc2 release is available References: <590096A3.5090107-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> <20170427070657.GA13585-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> <20170504084933.GA1359-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org> <9C6B67F36DCAFC479B1CF6A967258A8C7E953FA6-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org> <20170504153003.GA854-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> <1828884A29C6694DAF28B7E6B8A82373AB1199FA-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> <75ebb17e-cec3-6605-2a2f-d2533e95a5ec-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> <9C6B67F36DCAFC479B1CF6A967258A8C7E95451A-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org> In-Reply-To: <9C6B67F36DCAFC479B1CF6A967258A8C7E95451A-8oqHQFITsIFqS6EAlXoojrfspsVTdybXVpNB7YpNyf8@public.gmane.org> --8TJjCfwuE85JgbLqCuBGcxRvSti0xqIw4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. --=20 Doug Ledford GPG Key ID: B826A3330E572FDD Key fingerprint =3D AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FD= D --8TJjCfwuE85JgbLqCuBGcxRvSti0xqIw4-- --hKJEBndTvCcMXpUErWF2gw6gMeA17bNNn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJZC4u/AAoJELgmozMOVy/ds9IQAL5ff8N++8u5AZ0dXDETi+Fl xP/LD2sadq8YrV6PpHu0MYtarLWhuY6dUSpaU4yQID+SuhGp0ixjL+ijR2Hyv8GR Dh0lB28zfj/3VG7Wycm8bFIS9IDOnHL+FPb7mF6aRtfZeANLXOe5UavD+PkVN2ui SZV/UBHPqxPZBxMm4XH8sktyUhN5mvn5ZA6MknYNXbaQjr1+m/l6EV8OkockBN+b vsazAbPBBiYZc76pcVERV6nSrNiX+UJY1h6M9En/yNoBNSiNx2jCZUtCsYxISGsb gu6wvzOmIsm5Qe6LR6xmjprOpq7EGAE5S3L6iB0izGPpuTTFtxdPFvZhosysh5w3 stBiJrIgGDcfuL9mUiFJAROwJ2+aEEhZITsYB1gOCH50UTwvP7Fk7G42E5jRCBtD yLvs0L/ZBDOsS49BmOnWNjvCrOI8n9UCz1n0nDqRlZAZ9ohmketGZpANJyIIJxIH Ay04wqHPnvey+vM1fL8jTGLV4mzQkGlFZ0FepGnk6DnNW5ADUNs50eYeQw27Lgb+ dtTlDlOizNQRFeMfwIYPtyFSuiTQACHFV1JN7PaKH6SINf/hS/jdaSx53vXqxhIp A+dbh/JAQ2ho81P0kM5hRI4QFvxZz3SzZWsFwjtnponEz8+9Tqwv0KRvYgeplJxl eOzeOPXHPKP+hRQH6qrq =ikGf -----END PGP SIGNATURE----- --hKJEBndTvCcMXpUErWF2gw6gMeA17bNNn-- -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html