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 4F384A00BE; Wed, 30 Oct 2019 18:21:00 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9A4A11C0BC; Wed, 30 Oct 2019 18:20:59 +0100 (CET) Received: from smtp-4.sys.kth.se (smtp-4.sys.kth.se [130.237.48.193]) by dpdk.org (Postfix) with ESMTP id BC1E81C08C for ; Wed, 30 Oct 2019 18:20:57 +0100 (CET) Received: from smtp-4.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-4.sys.kth.se (Postfix) with ESMTP id 7FF88676D; Wed, 30 Oct 2019 18:20:57 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-4.sys.kth.se ([127.0.0.1]) by smtp-4.sys.kth.se (smtp-4.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FaMDFKqJMq89; Wed, 30 Oct 2019 18:20:56 +0100 (CET) Received: from exdb01.ug.kth.se (exdb01.ug.kth.se [192.168.32.111]) by smtp-4.sys.kth.se (Postfix) with ESMTPS id AE94E6910; Wed, 30 Oct 2019 18:20:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kth.se; s=default; t=1572456056; bh=fUsxGI8oEVyDrSAESewFFByTtfOCgHrU00rkyIe4rmU=; h=From:To:Subject:Date:References:In-Reply-To; b=evLEi+CPgslo8T0hZlOfZKpzGks4bcJZM9fLQtyv75O+ruFHKIeXT9ygMENA/Xmhv CQF3ywoezBRyxRo3ZBo5GY1U2DC/LfQjtSZV6rggbPMKSc64+fXLv82wMM5J/kl5uT z3caeXtssvVNOujEgQjOtc4n4hFuHVliy19Br6F4= Received: from exdb04.ug.kth.se (192.168.32.114) by exdb01.ug.kth.se (192.168.32.111) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 18:20:56 +0100 Received: from exdb05.ug.kth.se (192.168.32.115) by exdb04.ug.kth.se (192.168.32.114) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 18:20:55 +0100 Received: from exdb05.ug.kth.se ([192.168.32.115]) by exdb05.ug.kth.se ([192.168.32.115]) with mapi id 15.00.1473.005; Wed, 30 Oct 2019 18:20:56 +0100 From: Tom Barbette To: David Christensen , "dev@dpdk.org" Thread-Topic: [dpdk-dev] Performance impact of "declaring" more CPU cores Thread-Index: AQHVipD8PcLr2s+vNEeFpnLaXV0x8adrfp8AgAf2ZhM= Date: Wed, 30 Oct 2019 17:20:55 +0000 Message-ID: <1572456054835.87000@kth.se> References: , In-Reply-To: Accept-Language: fr-FR, sv-SE, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [91.176.21.55] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] Performance impact of "declaring" more CPU cores 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" Thanks for your comment. The raw number of cache misses is just higher almo= st in every function. While hwloc is indeed useful, the assignation is exac= tly the same in all cases. What we do is to define with "-l" more or less *= unused* cores. But the used ones run at the same place, with the same resou= rces and the same configuration.=0A= =0A= The only thing that may change is what DPDK does with those unused cores. E= g, allocate more unused per-core caches, etc. Shifting the allocation of ot= her caches, buffers, etc for the used cores, leading to more "unlucky" alig= nment and more contention.=0A= =0A= I'm trying to reproduce with the smallest possible modification of testpmd = so other people might experience this.=0A= =0A= Thanks,=0A= =0A= Tom =0A= ________________________________________=0A= De : David Christensen =0A= Envoy=E9 : vendredi 25 octobre 2019 19:35=0A= =C0 : Tom Barbette; dev@dpdk.org=0A= Objet : Re: [dpdk-dev] Performance impact of "declaring" more CPU cores=0A= =0A= > The only useful observation we made is that when we are in a "bad case",= =0A= > the LLC has more cache misses.=0A= =0A= Have you looked closely at the CPU topology on your platform, can you=0A= provide some examples here of what you're seeing? The hwloc package is=0A= very useful in visualizing how your logical cores map to CPU cache.=0A= There may be benefit is more strategically selecting the lcores you use=0A= to reduce LLC cache mssies.=0A= =0A= Dave=0A=