From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id 8D5607CB0 for ; Mon, 29 Apr 2019 18:39:49 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 0F6AA40013 for ; Mon, 29 Apr 2019 18:39:49 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id EFF1140014; Mon, 29 Apr 2019 18:39:48 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.1 X-Spam-Score: -0.9 Received: from [192.168.1.59] (host-90-232-38-87.mobileonline.telia.com [90.232.38.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 7765140013 for ; Mon, 29 Apr 2019 18:39:48 +0200 (CEST) To: "dev@dpdk.org" From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: <3d280f7e-057f-a35c-bd2f-db401e46e110@ericsson.com> Date: Mon, 29 Apr 2019 18:39:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [dpdk-dev] DPDK and Link-time Optimizations 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: Mon, 29 Apr 2019 16:39:49 -0000 Hi. Did anyone on the list successfully build DPDK with GCC Link-time Optimizations (LTO) enabled? I tried and failed a while back, although the detailed reasons of my failure eludes me for the moment. If LTO builds would work "out of the box", DPDK could gradually migrate from away from having static inline functions in the header files. Those interested squeezing out as much performance as possible would build with LTO (and static linking), and those applications who cared more about independent upgrades would use dynamic linking and non-LTO builds. With the extra cost of using DPDK as a shared library (-fPIC-compiled code, more expensive TLS accesses etc), I'm guessing this is the case already today. Regards, Mattias 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 E5E5DA0679 for ; Mon, 29 Apr 2019 18:39:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 551C17CCA; Mon, 29 Apr 2019 18:39:50 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id 8D5607CB0 for ; Mon, 29 Apr 2019 18:39:49 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 0F6AA40013 for ; Mon, 29 Apr 2019 18:39:49 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id EFF1140014; Mon, 29 Apr 2019 18:39:48 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.1 X-Spam-Score: -0.9 Received: from [192.168.1.59] (host-90-232-38-87.mobileonline.telia.com [90.232.38.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 7765140013 for ; Mon, 29 Apr 2019 18:39:48 +0200 (CEST) To: "dev@dpdk.org" From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: <3d280f7e-057f-a35c-bd2f-db401e46e110@ericsson.com> Date: Mon, 29 Apr 2019 18:39:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: [dpdk-dev] DPDK and Link-time Optimizations 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" Message-ID: <20190429163947.BBCbnUrDrNJMZBm1F309alj4-Qu0wz5ImYHlCd2UXjs@z> Hi. Did anyone on the list successfully build DPDK with GCC Link-time Optimizations (LTO) enabled? I tried and failed a while back, although the detailed reasons of my failure eludes me for the moment. If LTO builds would work "out of the box", DPDK could gradually migrate from away from having static inline functions in the header files. Those interested squeezing out as much performance as possible would build with LTO (and static linking), and those applications who cared more about independent upgrades would use dynamic linking and non-LTO builds. With the extra cost of using DPDK as a shared library (-fPIC-compiled code, more expensive TLS accesses etc), I'm guessing this is the case already today. Regards, Mattias