From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH 1/2] eal: add API to align integer to previous power of 2 Date: Mon, 19 Feb 2018 17:18:34 +0100 Message-ID: <4555376.PZvnTe3H9u@xps> References: <20180217104934.17291-1-pbhagavatula@caviumnetworks.com> <8522C580-BFB3-4D1B-A331-45DA05427D50@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: "jerin.jacob@caviumnetworks.com" , dev@dpdk.org To: Matan Azrad , "Wiles, Keith" , Pavan Nikhilesh Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id B53851B19 for ; Mon, 19 Feb 2018 17:18:54 +0100 (CET) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 19/02/2018 15:13, Matan Azrad: > Hi Wiles > > From: Wiles, Keith, Monday, February 19, 2018 3:56 PM > > > On Feb 19, 2018, at 12:03 AM, Matan Azrad wrote: > > >> Is this the type of API that needs to be marked experimental, > > > > > > I think it is relevant to any exposed API(not only for internal libraries). > > > > > >> we should be able to prove these functions, correct? > > > > > > Don't we need to prove any function in DPDK? > > > What is your point? > > > > > > My point is this is a inline function and can not be placed in the .map file as a > > external API. > > Doesn't each API in .h file external? Why not? > If it shouldn't be external and should be in .h file, I think it should be marked as internal, no? > > > These simple type of APIs are easy to prove and making them > > experimental seems to just cause an extra step. > > As Thomas mentioned here: > https://dpdk.org/ml/archives/dev/2018-January/087719.html > > Any new API should be experimental. > > Thomas, Is it different for .h file inline APIs? No, it is not different for inline functions. If we are discussing the policy for every function, it is not a policy anymore :) It was agreed to notify the users of the new functions, so it gives time to confirm the function before making it "stable". Even if the function looks obvious, I think we should follow the policy. So, yes, please add the experimental tag.