From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 056F1A0471 for ; Fri, 21 Jun 2019 19:41:06 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6FA2B1D52D; Fri, 21 Jun 2019 19:41:06 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 430AA1D50F for ; Fri, 21 Jun 2019 19:41:05 +0200 (CEST) Received: from [107.15.85.130] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1heNWX-0007bu-08; Fri, 21 Jun 2019 13:40:32 -0400 Date: Fri, 21 Jun 2019 13:40:23 -0400 From: Neil Horman To: David Marchand Cc: Aaron Conole , Adrien Mazarguil , Gage Eads , dev , Jerin Jacob Kollanukkaran , Van Haaren Harry , Nikhil Rao , Erik Gabriel Carrillo , Bruce Richardson , Pablo de Lara Message-ID: <20190621174023.GC21895@hmswarspite.think-freely.org> References: <20190620164206.3972-1-gage.eads@intel.com> <20190621162726.GA21895@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCH] eal: promote some service core functions to stable 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Fri, Jun 21, 2019 at 06:47:31PM +0200, David Marchand wrote: > On Fri, Jun 21, 2019 at 6:28 PM Neil Horman wrote: > > > On Fri, Jun 21, 2019 at 02:45:45PM +0200, David Marchand wrote: > > > Ok, did a new pass on the tree.. found quite some sites where we have > > > issues (and other discrepancies... I started a new patchset). > > > Looked at gcc documentation [1], and to me the safer approach would be to > > > enforce that __rte_experimental is the first thing of a symbol > > declaration. > > > > > > Comments? > > > > > Yes, thats the only way it works, in fact I'm suprised gcc didn't throw an > > error > > about expecting an asm statement if you put it anywhere else > > > > - I tried this, but then I hit issues with inlines. > Like for example: > > static inline char * __rte_experimental > rte_mbuf_buf_addr(struct rte_mbuf *mb, struct rte_mempool *mp) > { > return (char *)mb + sizeof(*mb) + rte_pktmbuf_priv_size(mp); > } > > I did not find a way to move the __rte_experimental tag without getting > warnings. Right, thats the way its supposed to work on gcc/icc/clang. function attributes must be declared between the return type and the function name, anything else will generate compiler warnings/errors. Because __rte_experimental expands to a __attribute__(...), you have to place it there. > If I try to compile some sources which includes rte_mbuf.h but without > -DALLOW_EXPERIMENTAL_API, then gcc errors at including the header, > complaining that rte_mbuf_buf_addr() is deprecated, even if this inline is > not called. > Thats...odd. I wonder if thats an artifact of the function being marked as inline. The compiler is supposed to insert the warning for any remaining calls after dead code eliminitaion. If the function is inline, I wonder if the compiler conservatively inserts the warning because it got expanded into another function, when it can't tell if it will be entirely elimintated. Can you provide a code sample that demonstrates this? > For now, I hid all those inlines under the ALLOW_EXPERIMENTAL_API flag. > > > - I have accumulated other fixes and I dropped all the marking in the .c > files. > This ended up with a huge series... > > 118 files changed, 867 insertions(+), 646 deletions(-) > > https://github.com/david-marchand/dpdk/commits/experimental > > I will let the week end pass on this. > > > -- > David Marchand