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=-5.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 51EA8C433FF for ; Tue, 30 Jul 2019 16:11:40 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 12539206A2 for ; Tue, 30 Jul 2019 16:11:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 12539206A2 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 66FA91BECD; Tue, 30 Jul 2019 18:11:39 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 661082BAE for ; Tue, 30 Jul 2019 18:11:38 +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 fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jul 2019 09:11:37 -0700 X-IronPort-AV: E=Sophos;i="5.64,327,1559545200"; d="scan'208";a="165889989" 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 09:11:35 -0700 Date: Tue, 30 Jul 2019 17:11:31 +0100 From: Bruce Richardson To: Stephen Hemminger Cc: Marcin Zapolski , dev@dpdk.org Message-ID: <20190730161131.GD1689@bricha3-MOBL.ger.corp.intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190730085413.550c979b@hermes.lan> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Jul 30, 2019 at 08:54:13AM -0700, Stephen Hemminger wrote: > On Tue, 30 Jul 2019 16:33:55 +0100 > Bruce Richardson wrote: > > > 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: > > > > > > > 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. > > > > > > > > Signed-off-by: Marcin Zapolski > > > > > > Sorry 2% matters. > > > > Note that this is with testpmd. Are there many apps out there where a 2% > > drop in IO cost would be noticable? > > 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. I'm all for getting it back, but the most likely place is in individual drivers themselves. Do you have a link on the static branches that the rest of us could read up on, since I, for one, am not familiar with the term.