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 A20A2A0613 for ; Tue, 30 Jul 2019 17:54:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 52C6B1BFF8; Tue, 30 Jul 2019 17:54:17 +0200 (CEST) Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by dpdk.org (Postfix) with ESMTP id C9D7B1BE41 for ; Tue, 30 Jul 2019 17:54:15 +0200 (CEST) Received: by mail-pf1-f193.google.com with SMTP id r1so30052875pfq.12 for ; Tue, 30 Jul 2019 08:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=9xZb+8YoG9fpbnMuZ7YBZK2Y7fp8Uwv2RwX5ww1tfkM=; b=xc2D1QUx6GeP2DkInWqssLIpok6Ud0bX3EZJdn97grbqDb3pXm2y/+XqDudT8N9QWc FlT0PPnHwimpfsYFaeBfCrJ0q033R07VHAjUq43UkCRh2O5QIsDRnr3awEcyAAHB8dLv BckfzTrWwE5Kho8v8X/wjDgDw5SpPupz959wYtuaC2CB7QXFiU4XLZ8Eqzq92NL8ivgG ZoVbDBF61VCHFrj0AiMm2A8Q1z+S7Pf/AWZooMWrVjvhnebN2IDirRmx+QFYFe5EeKB5 SiP9WE9E8RiHDISmOOXKUAd+oGLLoO2Mkxz0B3MDX3HIQZ0eE6iT4ad+9KnPafSiEXL/ KDbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=9xZb+8YoG9fpbnMuZ7YBZK2Y7fp8Uwv2RwX5ww1tfkM=; b=LVi0OoN/gAA0ndlq7NL30KEErQ++R2ul7uW5BFnv2S+aFbeN2vs7FFZ2gpgiEiTOaN tM9Ollh3DGSiSNhgyUR9bGOLl18B0yrTHF2cnSUF+PTAy0PxSbuO1geEyau+2CBSY73S +j3Dij/lV8iD3uiRGF9SU89Ibw5v6CkgwF3PRQZ2tOZ2d8HdBWCI84rD+YYoR+e+o4wL +se0t4x5X5Xav4qDAvdNgmBGqaSDS28oF5Ydz35r2hOuors48d8jXg8+DvmYCLArDwLe wVo/r0BXLWvd6jbhjtKUxQzFdjW5OFsxJyrWT4lSRWgnfcZydxYpP7kiD1hRF7t3dWtZ cu8A== X-Gm-Message-State: APjAAAUK7rIKTrG9u2VTYiNJ+avxB0FCHXv2BCjKE2jmoIlJEiu3vIdx cQP4A28QtJAQC61vItLl2dE= X-Google-Smtp-Source: APXvYqwQVuw4hrxujspkxfmGicxLH5f8jSebho3NYGfR899c4uKdf9HLEImw/RvVCRsbl5S1i5O+aw== X-Received: by 2002:a17:90a:21cc:: with SMTP id q70mr121305821pjc.56.1564502055020; Tue, 30 Jul 2019 08:54:15 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id q8sm131870220pjq.20.2019.07.30.08.54.14 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 30 Jul 2019 08:54:14 -0700 (PDT) Date: Tue, 30 Jul 2019 08:54:13 -0700 From: Stephen Hemminger To: Bruce Richardson Cc: Marcin Zapolski , dev@dpdk.org Message-ID: <20190730085413.550c979b@hermes.lan> In-Reply-To: <20190730153355.GB1689@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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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, 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.