From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 58BF043D7D; Fri, 29 Mar 2024 21:26:32 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EC7024014F; Fri, 29 Mar 2024 21:26:31 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 97F0740042; Fri, 29 Mar 2024 21:26:30 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 935C420E6F50; Fri, 29 Mar 2024 13:26:29 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 935C420E6F50 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1711743989; bh=sswKCqYJC7ehvurYAI2NwYf/FsoNC+IIHRuLmVCf780=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GCgtsKDQtuwSSUiAPOxsfBy/KhZUduK5qFSY6X31MLQZjlO4LmI7NWhSyA3uha1vE 4JLbVhO7HUkkhyoGFCWvkioP4cLr++X7r5eIfXcpUYHmx9ikncCexWxoLO3+P4xfJ5 I7IyS/Uxsydzoob1PT2Rth3+yD13VhMrBq8DhYFU= Date: Fri, 29 Mar 2024 13:26:29 -0700 From: Tyler Retzlaff To: Morten =?iso-8859-1?Q?Br=F8rup?= Cc: Maxime Coquelin , Stephen Hemminger , Andrey Ignatov , dev@dpdk.org, Chenbo Xia , Wei Shen , techboard@dpdk.org Subject: Re: The effect of inlining Message-ID: <20240329202629.GA19500@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20240328233338.56544-1-rdna@apple.com> <20240328164426.5b600cd1@hermes.local> <20240328195353.0dc838be@hermes.local> <319d86b3-c860-4231-b263-732aa4051531@redhat.com> <98CBD80474FA8B44BF855DF32C47DC35E9F33E@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9F33E@smartserver.smartshare.dk> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, Mar 29, 2024 at 02:42:49PM +0100, Morten Brørup wrote: > +CC techboard > > > From: Maxime Coquelin [mailto:maxime.coquelin@redhat.com] > > Sent: Friday, 29 March 2024 14.05 > > > > Hi Stephen, > > > > On 3/29/24 03:53, Stephen Hemminger wrote: > > > On Thu, 28 Mar 2024 17:10:42 -0700 > > > Andrey Ignatov wrote: > > > > > >>> > > >>> You don't need always inline, the compiler will do it anyway. > > >> > > >> I can remove it in v2, but it's not completely obvious to me how is > > it > > >> decided when to specify it explicitly and when not? > > >> > > >> I see plenty of __rte_always_inline in this file: > > >> > > >> % git grep -c '^static __rte_always_inline' lib/vhost/virtio_net.c > > >> lib/vhost/virtio_net.c:66 > > > > > > > > > Cargo cult really. > > > > > > > Cargo cult... really? > > > > Well, I just did a quick test by comparing IO forwarding with testpmd > > between main branch and with adding a patch that removes all the > > inline/noinline in lib/vhost/virtio_net.c [0]. > > > > main branch: 14.63Mpps > > main branch - inline/noinline: 10.24Mpps > > Thank you for testing this, Maxime. Very interesting! > > It is sometimes suggested on techboard meetings that we should convert more inline functions to non-inline for improved API/ABI stability, with the argument that the performance of inlining is negligible. removing inline functions probably has an even more profound negative impact when using dynamic linking. for all the value of msvc's dll scoped security features they do have overheads per-call that can't be wished away i imagine equivalents in gcc are the same. > > I think this test proves that the sum of many small (negligible) performance differences it not negligible! sure looks that way, though i think there is some distinction to be made between inline and *forced* inline. force inline may be losing us some opportunity for the compiler to optimize better than is obvious to us. > > > > > Andrey, thanks for the patch, I'll have a look at it next week. > > > > Maxime > > > > [0]: https://pastebin.com/72P2npZ0 >