From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8650BA0562; Wed, 1 Apr 2020 01:25:43 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DDF3E1C1BF; Wed, 1 Apr 2020 01:25:42 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 050131C1B9 for ; Wed, 1 Apr 2020 01:25:40 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4FCD85C01CA; Tue, 31 Mar 2020 19:25:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 31 Mar 2020 19:25:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=Uzt82HxE+PGAxuEWBP3JspzeTmoDsMh4wVQ+6eAPTDI=; b=fXwTgNIVYNmC W85zWo4ZFWJCctGYYQ0cJMEUV86SMBQxBeRiQ92067WwZhkA5YeFTBk1uuVr6XeA xo5Y0CGLJbjc5hvnlBLaPftPPA0z0RUeUnlkv6gNkx1gx9/J+dZA64HLp1ACo9zM wI3gdo8z1b1AUNlPs/VkFNwc0WzHGDA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Uzt82HxE+PGAxuEWBP3JspzeTmoDsMh4wVQ+6eAPT DI=; b=uitHpAMX8kwpGDSzFrVNNENtIAxtMPM2ecFCbXG73fKzUk2cn7AII9JhL oSLq67AIb2/XgadaSdA/6Fc4E15jJdTpuujibDrwu/JK/ZPsctkj1f0lAGC6LPzE 90loJOXL9ZgycAevRPN+Z744cdsBVlIWxXybHbbJdpbdVbw2uBvGL7lp0MvEMINK z2qyKpgGIItq17fy3GzwlXHBrvxWrKGbHqJtGbuJ5Y0Gg0Ym0bQgG1UnUXMGE1pa AGMPb4iwtgv4oEzzpjAjHRFo2pbDbin95zq7n/a/ARR4X8XmBK+DZjeOJqHZNaJ1 2N/pFcMcZPNKriF4eZSpFWH11xlRg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtddtgdduheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttddunecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrddvtdefrddukeegnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrg hssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id B9E36306CC17; Tue, 31 Mar 2020 19:25:37 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob , Konstantin Ananyev , Jerin Jacob , Morten =?ISO-8859-1?Q?Br=F8rup?= Cc: dev@dpdk.org, Olivier Matz , Honnappa Nagarahalli , David Christensen , Stephen Hemminger Date: Wed, 01 Apr 2020 01:25:35 +0200 Message-ID: <2445314.H8VbNj7W2P@xps> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35C60F05@smartserver.smartshare.dk> References: <20200320164138.8510-1-konstantin.ananyev@intel.com> <98CBD80474FA8B44BF855DF32C47DC35C60F05@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] [RFC] ring: make ring implementation non-inlined 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" 26/03/2020 09:04, Morten Br=F8rup: > From: Jerin Jacob > > On Fri, Mar 20, 2020 Konstantin Ananyev wrote: > > > > > > As was discussed here: > > > http://mails.dpdk.org/archives/dev/2020-February/158586.html > > > this RFC aimed to hide ring internals into .c and make all > > > ring functions non-inlined. In theory that might help to > > > maintain ABI stability in future. > > > This is just a POC to measure the impact of proposed idea, > > > proper implementation would definetly need some extra effort. > > > On IA box (SKX) ring_perf_autotest shows ~20-30 cycles extra for > > > enqueue+dequeue pair. On some more realistic code, I suspect > > > the impact it might be a bit higher. > > > For MP/MC bulk transfers degradation seems quite small, > > > though for SP/SC and/or small transfers it is more then noticable > > > (see exact numbers below). > > > From my perspective we'd probably keep it inlined for now > > > to avoid any non-anticipated perfomance degradations. > > > Though intersted to see perf results and opinions from > > > other interested parties. > >=20 > > +1 Konstantin, thank you for doing some measures > > My reasoning is a bit different, DPDK is using in embedded boxes too > > where performance has more weight than ABI stuff. >=20 > As a network appliance vendor I can confirm that we certainly care > more about performance than ABI stability. > ABI stability is irrelevant for us; > and API instability is a non-recurring engineering cost each time > we choose to switch to a new DPDK version, which we only do if we > cannot avoid it, e.g. due to new drivers, security fixes or > new features that we want to use. >=20 > For us, the trend pointed in the wrong direction when DPDK switched > the preference towards runtime configurability and deprecated compile > time configurability. I do understand the reasoning behind it, > and the impact is minimal, so we accept it. The code can be optimized by removing some instructions with #ifdef. But the complexity of managing #ifdef enabling/disabling, depending on the platform and the use case, would be huge. We try to have a reasonable code "always enabled" which performs well in all cases. This is a design choice which makes DPDK a library, not a pool of code to cherry-pick. > However, if DPDK starts sacrificing performance of the core > libraries for the benefits of the GNU/Linux distributors, > network appliance vendors may put more effort into sticking > with old DPDK versions instead of updating. The initial choice regarding ABI compatibility was "do not care". Recently, the decision was done to care about ABI compatibility as priority number 2. The priority number 1 remains the performance. That's a reason for allowing some ABI breakages in some specific releases announced in advance. > > I think we need to focus first on slow > > path APIs ABI stuff. Yes we should not degrade fast path performance for the sake of avoiding uncertain future ABI issues. Morten, Jerin, thank you for the feedback.