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 A12CCA0471 for ; Fri, 21 Jun 2019 21:58:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6EDAE1D53F; Fri, 21 Jun 2019 21:58:55 +0200 (CEST) Received: from mail-ua1-f65.google.com (mail-ua1-f65.google.com [209.85.222.65]) by dpdk.org (Postfix) with ESMTP id 6C89B1D537 for ; Fri, 21 Jun 2019 21:58:53 +0200 (CEST) Received: by mail-ua1-f65.google.com with SMTP id c4so3453079uad.1 for ; Fri, 21 Jun 2019 12:58:53 -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=R3d0VjvS+B3QvKWZxhzKJvsT5AHcha4ZFloX5VnWdPs=; b=IYJNOGfhcSLjqapn12CL84EnulqWJZaaP/oJtdYgNt2sTLYavMa1zd1m0bEeLWCPc2 8WQ6W/m+jy0gOpGVjbiAadojTKGh0ur+DL/qwRAVDn3hwkjnxsjT30s67hNL0JgrcbOe H8FBCor51Na8zCH/a3/yte6QTI4GUqKAdeWNv9tyuK4eNv522RcKIZvNwgNMRufYC4FK bfTG+yfyW3wT9KH1NdkDZFy3BctxM5Bq6EvVmmhNSG/EflSzt+cJa0H2ozwZMORo3STU bVd32MbwHs8qDhjI6b+m/K1XkG07c1Dw7JKDb0PosLB2a5ZJvMOn4KOzkahLZtD8+YGV OrkQ== X-Gm-Message-State: APjAAAXRoSrC9Vt04aA33aq4ivYAQ/I3qgfn8IdKvyneLcy7s7FHbmNV vAeVPerxkP81ToUWwsdwKEd045p2k7W7eIeghloTmQ== X-Google-Smtp-Source: APXvYqzW1BHuW2+DcUQ3xB2exm6nJxRCrr8VdGZVB71u/Z9B8b+eEuU7Dhq7M2lRrmUuNZCcPwmKxQ1bZqmB/xN9/SA= X-Received: by 2002:ab0:45e3:: with SMTP id u90mr19373990uau.126.1561147132737; Fri, 21 Jun 2019 12:58:52 -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> In-Reply-To: <20190621174023.GC21895@hmswarspite.think-freely.org> From: David Marchand Date: Fri, 21 Jun 2019 21:58:41 +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 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 we ha= ve > > > > 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 (declared a= t deprecated.c:1) [-Wdeprecated-declarations] plap(); ^ --=20 David Marchand