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 30744A0471 for ; Sat, 22 Jun 2019 19:51:26 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BC92C1C3AB; Sat, 22 Jun 2019 19:51:24 +0200 (CEST) Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) by dpdk.org (Postfix) with ESMTP id 6E4B71C33C for ; Sat, 22 Jun 2019 19:51:22 +0200 (CEST) Received: by mail-ua1-f41.google.com with SMTP id o19so4135052uap.13 for ; Sat, 22 Jun 2019 10:51:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1ao9sPwiBqd5YFHBLhb6uYChzG48sYER6sqBxfq+kQ8=; b=B/muZuyhbSYthDU+70yBDPLz6JLNhkFhbgigDUTKoW3FKlP3ekHreB8rwSzSv4zTxg +KWTfGjdtByzx1pGYo0D055rmUfP/tT02OPWRO39hm2G67TBH8XHyU3p2h9qdujOBRlJ 0ZQyZoXI7iX3KfVL7xBFQ7EBDIcDQ63aEa6lnCWBm7K26Y/6DwuYoAMBx8qi0eg+OInG FQfuBt67jveJnT0xxdlmVXWf0AgKThWoWuX20HwO8UcC/bpSk9I4FWGSM2ed8LTetcLx 4DmSKoPX03ngE5vEseLjqBu1TKHrK0gFf/C+dd9kcDwrtCR5GQMMiziy1H3G+TbZ784z WlJQ== X-Gm-Message-State: APjAAAWPapvlu9gYZar2YFQQDUWt6/hT33s09IR6q1Oy/lsGCe+rbJxo ZG4yLtB0ApzpuppL+8vPnN1b9zreywuCWg6ZQIYW3Q== X-Google-Smtp-Source: APXvYqwDgb3pd/cAXs/QmYYGb0KB8H85bkjH3qyHjB0RRQGT1dP1pTn/KdCTRmvc4XkQ5wq8GPQ7LI8nI/Sf5zi/cR4= X-Received: by 2002:ab0:168a:: with SMTP id e10mr62742592uaf.87.1561225881752; Sat, 22 Jun 2019 10:51:21 -0700 (PDT) MIME-Version: 1.0 References: <20190620164206.3972-1-gage.eads@intel.com> <20190621162726.GA21895@hmswarspite.think-freely.org> <20190621174023.GC21895@hmswarspite.think-freely.org> <20190622161700.GB16476@hmswarspite.think-freely.org> In-Reply-To: <20190622161700.GB16476@hmswarspite.think-freely.org> From: David Marchand Date: Sat, 22 Jun 2019 19:51:10 +0200 Message-ID: To: Neil Horman Cc: Aaron Conole , Adrien Mazarguil , Gage Eads , dev , Jerin Jacob Kollanukkaran , Van Haaren Harry , Nikhil Rao , Erik Gabriel Carrillo , Bruce Richardson , Pablo de Lara Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 Sat, Jun 22, 2019 at 6:17 PM Neil Horman wrote: > On Fri, Jun 21, 2019 at 09:58:41PM +0200, David Marchand wrote: > > On Fri, Jun 21, 2019 at 7:41 PM Neil Horman > wrote: > > > > > 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 w= e > 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? > > > > > > > > rte_mbuf_buf_addr() is called in rte_mbuf_data_addr_default(), both of > them > > are unused by the includers of rte_mbuf.h. > > > > > > Reproduced it like this: > > > > [dmarchan@dmarchan ~]$ cat deprecated.c > > __attribute__((deprecated)) static inline void *plap(void) > > { > > return 0; > > } > > > > __attribute__((deprecated)) static inline void *plep(void) > > { > > plap(); > > return 0; > > } > > > > int main(int argc, char *argv[]) > > { > > return 0; > > } > > [dmarchan@dmarchan ~]$ gcc -o deprecated -Wall deprecated.c > > deprecated.c: In function =E2=80=98plep=E2=80=99: > > deprecated.c:8:2: warning: =E2=80=98plap=E2=80=99 is deprecated (declar= ed at > > deprecated.c:1) [-Wdeprecated-declarations] > > plap(); > > ^ > > > Hmm, yes, that seems buggy to me. I wonder if you are seeing this bug in > action: > > https://gcc.gnu.org/bugzilla//show_bug.cgi?id=3D80680 It has the same flavor yes. Currently using gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) > > Seem like the behavior fits. It would be interesting to know if clang an= d > icc > suffer from the same issue > Just tried, clang is fine. clang version 3.4.2 (tags/RELEASE_34/dot2-final) Actually, I went and protected this call to rte_mbuf_buf_addr(). And with just this, it builds fine. I think I am going to take this approach, just a little comment :-). --=20 David Marchand