From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 8EF1EA0613 for <public@inbox.dpdk.org>; Tue, 30 Jul 2019 17:32:13 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 97A701BF13; Tue, 30 Jul 2019 17:32:12 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id E53FD1BF09 for <dev@dpdk.org>; Tue, 30 Jul 2019 17:32:10 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2019 08:32:09 -0700 X-IronPort-AV: E=Sophos;i="5.64,327,1559545200"; d="scan'208";a="165878813" Received: from bricha3-mobl.ger.corp.intel.com ([10.251.80.128]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2019 08:32:07 -0700 Date: Tue, 30 Jul 2019 16:32:03 +0100 From: Bruce Richardson <bruce.richardson@intel.com> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com> Cc: Marcin Zapolski <marcinx.a.zapolski@intel.com>, "dev@dpdk.org" <dev@dpdk.org> Message-ID: <20190730153203.GA1689@bricha3-MOBL.ger.corp.intel.com> References: <20190730124950.1293-1-marcinx.a.zapolski@intel.com> <20190730124950.1293-2-marcinx.a.zapolski@intel.com> <BYAPR18MB2424C7D1982A4A3D5ED76C76C8DC0@BYAPR18MB2424.namprd18.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <BYAPR18MB2424C7D1982A4A3D5ED76C76C8DC0@BYAPR18MB2424.namprd18.prod.outlook.com> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions non-inline X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Tue, Jul 30, 2019 at 03:01:00PM +0000, Jerin Jacob Kollanukkaran wrote: > > -----Original Message----- From: dev <dev-bounces@dpdk.org> On Behalf > > Of Marcin Zapolski Sent: Tuesday, July 30, 2019 6:20 PM To: > > dev@dpdk.org Cc: Marcin Zapolski <marcinx.a.zapolski@intel.com> > > Subject: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions > > non- inline > > > > Make rte_eth_rx_burst, rte_eth_tx_burst and other static inline ethdev > > functions not inline. They are referencing DPDK internal structures and > > inlining forces those structures to be exposed to user applications. > > > > In internal testing with i40e NICs a performance drop of about 2% was > > observed with testpmd. > > I tested on two class of arm64 machines(Highend and lowend) one has 1.4% > drop And other one has 3.6% drop. > This is with testpmd only right? I'd just point out that we need to remember that these numbers need to be scaled down appropriately for a realworld app where IO is only a (hopefully small) proportion of the packet processing budget. For example, I would expect the ~2% drop we saw in testpmd to correspond to <0.5% drop in something like OVS. > I second to not expose internal data structure to avoid ABI break. > > IMO, This patch has performance issue due to it is fixing it in simple > way. > > It is not worth two have function call overhead to call the driver > function. Some thoughts below to reduce the performance impact without > exposing internal structures. > The big concern I have with what you propose is that would involve changing each and every ethdev driver in DPDK! I'd prefer to make sure that the impact of this change is actually felt in real-world apps before we start looking to make such updates across the DPDK codebase. > And I think, We need to follow the similar mechanism for cryptodev, Eventdev, rawdev > Etc so bring the common scheme to address this semantics will be use full. > Agreed. Regards, /Bruce