From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 6D5472C2E for ; Sun, 21 Jan 2018 19:55:22 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C3AA3201D0; Sun, 21 Jan 2018 13:55:21 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Sun, 21 Jan 2018 13:55:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=9CNtu+CDhi5CGf2VVRL/MH/lD6 nND9rYXAqMwLxPXmc=; b=rAdGyCeYIKCNOZII+pKYy8lIDEJXc5qnxi+i3iu08o BO1tO8zDbjQeUxM6XygI7HpjpiSF1D+XJRP3aB8FN61SQk5CZei3AldJzBe8iUyu BcXcIhPQ7pBiLRDeXIZG3XdfQNvrrZyLMS0rZLiOFUNHdaNIAKAVVm6V63WtgT83 I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=9CNtu+ CDhi5CGf2VVRL/MH/lD6nND9rYXAqMwLxPXmc=; b=HMRKcyiOYIUVZz43nVGUB9 8BLZ6+ZfIemLdSOfo6JP+/fWVVnYllyTsAT836VfD5LCjIca3dfja1mdXWOpvExQ BGuTSs7MF+7O8Ctyu/H3VU+0bsUh3a6UGGTw46CCxXDhIh0ykrmLBzK2wGQTaDLZ Ay43ss4pGHsaI8Af1/lXnmt4ZhhAAv7DtjuIbvqflj2lCW0oNv2U2RMKRH/ABVyk +T11CXsunny1NPof1yaen/HHKDMLw3yCdOUbNxQ1RXTP9HThFAESX1Ph66dReP29 d3Boy3u2pLzGakK9/tsM4FSze7j8UCE5Wil8a+u/4UN6BDdEQDs8Am/XXnWHxtKQ == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 6C19624736; Sun, 21 Jan 2018 13:55:21 -0500 (EST) From: Thomas Monjalon To: Neil Horman Cc: dev@dpdk.org, Ferruh Yigit , john.mcnamara@intel.com, bruce.richardson@intel.com Date: Sun, 21 Jan 2018 19:54:44 +0100 Message-ID: <2231669.8C7kkI4IjB@xps> In-Reply-To: <20180112124459.GA20015@hmswarspite.think-freely.org> References: <20171201185628.16261-1-nhorman@tuxdriver.com> <20180112124459.GA20015@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCHv4 3/5] Makefiles: Add experimental tag check and warnings to trigger on use X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jan 2018 18:55:22 -0000 12/01/2018 13:44, Neil Horman: > On Fri, Jan 12, 2018 at 11:49:57AM +0000, Ferruh Yigit wrote: > > On 1/11/2018 8:50 PM, Neil Horman wrote: > > > On Thu, Jan 11, 2018 at 08:06:43PM +0000, Ferruh Yigit wrote: > > >> On 12/13/2017 3:17 PM, Neil Horman wrote: > > >>> --- a/app/test-eventdev/Makefile > > >>> +++ b/app/test-eventdev/Makefile > > >>> @@ -32,6 +32,7 @@ include $(RTE_SDK)/mk/rte.vars.mk > > >>> > > >>> APP = dpdk-test-eventdev > > >>> > > >>> +CFLAGS += -DALLOW_EXPERIMENTAL_APIS > > >> > > >> Do we need this internally in DPDK? For application developers this is great, > > >> they will get warning unless explicitly stated that they are OK with it. > > >> > > > I'm not sure what you're asking here. As I mentioned in the initial post, I > > > think we should give blanket permission to any in-tree dpdk library to allow the > > > use of experimental API's, but that doesn't really imply that all developers > > > would wan't it disabled all the time. That is to say, I could envision a > > > library author who, early in development would want to get a warning issued if > > > they used an unstable API, and, only once they were happy with their design and > > > choice of API usage, turn the warning off. > > > > I got your point, but I think whoever using an experimental API in another > > component in DPDK is almost always the author of the that experimental API, so > > not sure this check is ever really needed within dpdk. > > > I would have thought so too, but it doesn't really bear up. The example I used > to convince myself of a more granular approach was commit > 9c38b704d280ac128003238d7d80bf07fa556a7d where the rte_service API was > introduced as experimental by Nikhil Rao, and then later used in the eal library > as part of commit a894d4815f79b0d76527d9c42b23327de1501711 by Harry van Haaren. > Its no big deal because, as we agree, internal usage should be considered safe, > but it seemed clear that differing authors were using each others code > (potentially oblivious to the experimental nature of those APIs) > > > But OK, I guess it won't hurt to have more granular approach. > > > > > > > >> Do we have any option than allowing them in DPDK library? And when experimental > > >> API modified the users in the DPDK library internally guaranteed to be updated. > > >> Why not globally allow this for all DPDK internally? > > >> > > > For the reason I gave above. We certainly could enable this in a more top-level > > > makefile so that for in-library systems it was opt-in rather than opt-out, but I > > > chose a more granular approach because I could envision newer libraries wanting > > > it on. I also felt, generally speaking, that where warning flags were > > > concerned, it generally desireous to have them on by default, and make people > > > explicitly choose to turn them off. I think DPDK developpers look at the EXPERIMENTAL warning in the doxygen above the prototype. And when API will be switched to stable, we probably won't remove the flag in the makefile to disable allowing experimental. So at the end, we could just allow experimental API for all internal libs.