From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Ledford Subject: Re: Upcoming libibverbs release Date: Tue, 19 Jul 2016 15:57:03 -0400 Message-ID: References: <3b89c411-72be-ddc5-5ebf-009eeee29692@redhat.com> <4ec1d8e6-a908-bb49-a137-415856ec6faa@dev.mellanox.co.il> <20160627181758.GD23540@obsidianresearch.com> <20160628050246.GB3584@leon.nu> <20160628162028.GA27518@obsidianresearch.com> <20160628170549.GE3584@leon.nu> <022001d1d170$fda2c3e0$f8e84ba0$@opengridcomputing.com> <20160628211441.GA5786@obsidianresearch.com> <1828884A29C6694DAF28B7E6B8A82373AB0663DA@ORSMSX109.amr.corp.intel.com> <20160629051956.GG3584@leon.nu> <20160629183042.GC17031@obsidianresearch.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RM8IaCdFnTt4xCuLmvdPu84mCrCihp3Qf" Return-path: In-Reply-To: <20160629183042.GC17031-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> Sender: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jason Gunthorpe , Leon Romanovsky Cc: "Hefty, Sean" , Steve Wise , 'Yishai Hadas' , 'linux-rdma' , 'Yishai Hadas' , 'Matan Barak' , 'Majd Dibbiny' , "talal-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org" List-Id: linux-rdma@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RM8IaCdFnTt4xCuLmvdPu84mCrCihp3Qf Content-Type: multipart/mixed; boundary="31fVfFFVVOxRXSNUAru3tA0vLMqeLbUFp" From: Doug Ledford To: Jason Gunthorpe , Leon Romanovsky Cc: "Hefty, Sean" , Steve Wise , 'Yishai Hadas' , 'linux-rdma' , 'Yishai Hadas' , 'Matan Barak' , 'Majd Dibbiny' , "talal-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org" Message-ID: Subject: Re: Upcoming libibverbs release References: <3b89c411-72be-ddc5-5ebf-009eeee29692-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> <4ec1d8e6-a908-bb49-a137-415856ec6faa-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> <20160627181758.GD23540-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> <20160628050246.GB3584-2ukJVAZIZ/Y@public.gmane.org> <20160628162028.GA27518-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> <20160628170549.GE3584-2ukJVAZIZ/Y@public.gmane.org> <022001d1d170$fda2c3e0$f8e84ba0$@opengridcomputing.com> <20160628211441.GA5786-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> <1828884A29C6694DAF28B7E6B8A82373AB0663DA-P5GAC/sN6hkd3b2yrw5b5LfspsVTdybXVpNB7YpNyf8@public.gmane.org> <20160629051956.GG3584-2ukJVAZIZ/Y@public.gmane.org> <20160629183042.GC17031-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> In-Reply-To: <20160629183042.GC17031-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> --31fVfFFVVOxRXSNUAru3tA0vLMqeLbUFp Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/29/2016 2:30 PM, Jason Gunthorpe wrote: > On Wed, Jun 29, 2016 at 08:19:56AM +0300, Leon Romanovsky wrote: >> On Tue, Jun 28, 2016 at 09:26:38PM +0000, Hefty, Sean wrote: >>>> The fundamental question is if it is acceptable for libibverbs to sh= ip >>>> a new core provider agnostic API (cq polling) that is optional >>>> depending on provider. >>>> >>>> I say no, that is not acceptable. >>> >>> I agree - there's no compelling argument that the new calls can't wor= k over all providers. >> >> I agree too, this is why code is provided and nothing stops from other= provider to support it. >=20 > That isn't what I said, and it isn't what everyone is agreeing with. >=20 > I said an optinal API is not acceptable to ship. >=20 > That means 'nothing stops' is not enough - the patch author and > maintainer have the responsibility to ensure all providers work with > the API before shipping it. That's not entirely true. In the kernel, if someone cuts over stuff from one API to a replacement API, then yes, they are responsible for updating all of the users of the old API. But if they create a new API that is in addition to the old API, then that's not the case. This falls in that latter category. That said, there is no reason that owners of various driver libraries can't update their own libraries to this API. As we already discussed in another thread when Steve Wise brought up the issue of how things would look if we put the providers into the same package as libibverbs, distros and such have their own schedules and the day we release something here is not the same day they pick things up there, so we should have sufficient time to update libibverbs and then cut over the driver modules. They don't have to happen on the same day. What I don't want is a core compat layer in libibverbs. The changes needed to support just the pull cq changes are not that drastic and they have benefit that would be lost in a compat layer, so I would rather see them done natively on a per library basis. --=20 Doug Ledford GPG Key ID: 0E572FDD --31fVfFFVVOxRXSNUAru3tA0vLMqeLbUFp-- --RM8IaCdFnTt4xCuLmvdPu84mCrCihp3Qf 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/ iQIcBAEBCAAGBQJXjoYPAAoJELgmozMOVy/dZroQAK2nCHadr7vPoyUAhfGLtGtw d8KFU2GV5BUOLs34aroxsrhRPt2eL3kOdAA1ZAQzXifRWx512SXKV6gU91uV/0pu ID6sePCwUVvt34hDqYg3amQk2GZGg/VkQcsGnaJgw2G/zX7RQC+nRxAVbKBpzI05 06DaIrxGwwktIP5VFa3yMK3BLc1L2uK1V7XxEMcU8ExETUDLnkJ6Spe5WybMc+cL DTA/tk4g/mpL1nbpvOy1Ks7NJJtXKSgCGEyHP2w/DMENpAEkJeoDkU2Gi155dX7v Zt6kP0RivsKK0lhFs8hkEzE5WbWhsOdf3yy6BH+rxW3rsyxUbOAtl2qFbaWg7P8x 5W/Tx4n7RK6iGTQYS67stk3m8bkcquPmni0Pfi7ZvKCrG7l9/q0+XasVEPNuXfX1 c2dFXOEvixyCiwu9dQVzYLsrrKfU8SloxvVzQLS130twaEao3Nh6I3lxMfgmOpRq rVw58nJMpOCiFNcRGVDGOtrafsOzmkWE7tBYi0Takt9BMqYYxf6B8eQdknTFcGPz hUsHx8qCuqw6VfRknjJmO0tuMjzRFlSXjqA7ag4RTzPuJeG+4OcF7tgtPHOyCBfI La0CDYtCKSKh1p7wMEIJxMps/pNY0fmYuw72+r9DXd5jL8rjx5kTyoo7huG6krUh SOqojmF8cBwOntug1JUu =W+wH -----END PGP SIGNATURE----- --RM8IaCdFnTt4xCuLmvdPu84mCrCihp3Qf-- -- 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