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 4FE61A0613 for ; Tue, 30 Jul 2019 18:23:21 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 8452C1BF08; Tue, 30 Jul 2019 18:23:20 +0200 (CEST) Received: from mail-pf1-f195.google.com (mail-pf1-f195.google.com [209.85.210.195]) by dpdk.org (Postfix) with ESMTP id 1855B1BED9 for ; Tue, 30 Jul 2019 18:23:20 +0200 (CEST) Received: by mail-pf1-f195.google.com with SMTP id r7so30108287pfl.3 for ; Tue, 30 Jul 2019 09:23:19 -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=oj+AJ4lBnm6S0sgRMVhIDqhp3pUtsNmb8+hZ4PamFWM=; b=ukQnKLXMZhD+2qDvQ3B5Iw9SAv+ep9ZDaEEyfCn/T8fk71YSeh1mSNkAmwDet3zL9o gpSwTRBs2rtLhAph+fcSX7aS5H1APvV8pAEzYJivsKddHyGxKERn2O+FIXVb4lMWDUpR pxMsmS/L9OAAFLNmuIhx+jyyj/ZNxV1FkgoskpCmKfTTI+KBJddrDE1KxjcyExTIr5hj UxV861iu0evQBMYVD0PpAKtmKTjgpjoK12hXSusKTZBZ7SZj2Yo5QIQ5NThEi62tsXTt AijyK9r7lcxwa7dt/d5oLiNEpeMR8hFzD49gjJW6t3Kqdk3Ih62MvFntYKScJvtvsZyG Z2Tw== 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=oj+AJ4lBnm6S0sgRMVhIDqhp3pUtsNmb8+hZ4PamFWM=; b=tAHVWnUblMNSfgNlpU9ERoOyVKezeDvwM9dmb39/rsl5i4YpdsoMBp6wM6xpBaQqBE D6jXIf/U8oCSeR1oWi0g9xIduaKAIhp7IDaVGx340XfAZymr7G3v0TVgPxBk1k+5PN0/ +awwHLSu7JWzm+OD/ACBFzffl/XTtLyg8jPA/e3Q2WWRz8D4mXdlnJEiflRmyBu8dDkk mSsQuJjjBLeqdTY+lwoXEJ8euJ9RgzXGi7un96B+w5KJ+zWqnU9/FAuU+l0WWQIEVNr5 tIABpoC7vHZElfH5ABxVopP+RJrZXHt8IsKl8oJdycEAOlW1t/VNuI9kKgKjOMZf4vUC dqqg== X-Gm-Message-State: APjAAAW25Kr7vsDOWYeXQYFOZQWaVK0IfwOSXm+9uyCUlwRKOWMaPAGF ObwcmmVl5n2ZoNYOAOVRbHA= X-Google-Smtp-Source: APXvYqwhSPDWrL1QrjfbxFCaDCAA9lZimHOertzZkXaNko5xi2w2Cgr3DyXha35qN6l1Jr8YjviuIw== X-Received: by 2002:a63:ea50:: with SMTP id l16mr111569534pgk.160.1564503799053; Tue, 30 Jul 2019 09:23:19 -0700 (PDT) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id p23sm71187215pfn.10.2019.07.30.09.23.18 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 30 Jul 2019 09:23:18 -0700 (PDT) Date: Tue, 30 Jul 2019 09:23:12 -0700 From: Stephen Hemminger To: Bruce Richardson Cc: Marcin Zapolski , dev@dpdk.org Message-ID: <20190730092312.51549aba@hermes.lan> In-Reply-To: <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> <20190730161131.GD1689@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 17:11:31 +0100 Bruce Richardson wrote: > 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. https://www.kernel.org/doc/Documentation/static-keys.txt