From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0C2DDC0650F for ; Tue, 30 Jul 2019 16:04:37 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 9DBD620693 for ; Tue, 30 Jul 2019 16:04:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9DBD620693 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BAE561C0C1; Tue, 30 Jul 2019 18:04:34 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 600181C022 for ; Tue, 30 Jul 2019 18:04:32 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2019 09:04:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.64,327,1559545200"; d="scan'208";a="323248170" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga004.jf.intel.com with ESMTP; 30 Jul 2019 09:04:31 -0700 Received: from fmsmsx118.amr.corp.intel.com ([169.254.1.125]) by FMSMSX105.amr.corp.intel.com ([169.254.4.116]) with mapi id 14.03.0439.000; Tue, 30 Jul 2019 09:04:30 -0700 From: "Wiles, Keith" To: Stephen Hemminger CC: "Richardson, Bruce" , "Zapolski, MarcinX A" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC 19.11 1/2] ethdev: make DPDK core functions non-inline Thread-Index: AQHVRusc0Z9ZC3e+N0m9qfTwjMoOAqbjv+eAgAAFrICAAALegA== Date: Tue, 30 Jul 2019 16:04:29 +0000 Message-ID: References: <20190730124950.1293-1-marcinx.a.zapolski@intel.com> <20190730124950.1293-2-marcinx.a.zapolski@intel.com> <20190730082534.7f2138ee@hermes.lan> <20190730153355.GB1689@bricha3-MOBL.ger.corp.intel.com> <20190730085413.550c979b@hermes.lan> In-Reply-To: <20190730085413.550c979b@hermes.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.185.164] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > On Jul 30, 2019, at 10:54 AM, Stephen Hemminger wrote: >=20 > On Tue, 30 Jul 2019 16:33:55 +0100 > Bruce Richardson wrote: >=20 >> On Tue, Jul 30, 2019 at 08:25:34AM -0700, Stephen Hemminger wrote: >>> On Tue, 30 Jul 2019 14:49:49 +0200 >>> Marcin Zapolski wrote: >>>=20 >>>> Make rte_eth_rx_burst, rte_eth_tx_burst and other static inline ethdev >>>> functions not inline. They are referencing DPDK internal structures an= d >>>> inlining forces those structures to be exposed to user applications. >>>>=20 >>>> In internal testing with i40e NICs a performance drop of about 2% was >>>> observed with testpmd. >>>>=20 >>>> Signed-off-by: Marcin Zapolski =20 >>>=20 >>> Sorry 2% matters. =20 >>=20 >> Note that this is with testpmd. Are there many apps out there where a 2% >> drop in IO cost would be noticable? >=20 > Why not find a way to get the 2% back elsewhere? Maybe analyzing the code= /cache > in more detail. Perhaps some prefetching could help, or getting rid of > indirect calls elsewhere in the code. At the extreme, maybe implementing > something like the kernel static branches (self-modifying code) would > get a lot back. +1, I discussed something very similar internally or at least let's not red= uce DPDK performance by 2% and find a different way. Regards, Keith