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 27F02A317C for ; Thu, 17 Oct 2019 18:18:23 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D3B891D428; Thu, 17 Oct 2019 18:18:21 +0200 (CEST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id 169291D426 for ; Thu, 17 Oct 2019 18:18:20 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Oct 2019 09:18:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.67,308,1566889200"; d="scan'208";a="186535726" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.104]) ([10.237.220.104]) by orsmga007.jf.intel.com with ESMTP; 17 Oct 2019 09:18:18 -0700 To: David Christensen , David Marchand Cc: dev References: <20190925214223.79362-1-drc@linux.vnet.ibm.com> From: "Burakov, Anatoly" Message-ID: <2b23f288-242e-b280-4ec5-c790e777c4fc@intel.com> Date: Thu, 17 Oct 2019 17:18:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] eal:ppc: fix incorrect ifdef for ppc_64 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 16-Oct-19 9:45 PM, David Christensen wrote: >>> An ifdef present in eal_memory.c references "RTE_ARCH_PPC64" when >>> it should actually use "RTE_ARCH_PPC_64".  Simple testing revealed >>> that both the PPC_64 and non-PPC_64 versions of the code involved >>> work, but the PPC_64 version of the code is retained to be >>> consistent with other instances in the same file where mmapped >>> memory is accessed in reverse order on Power platforms. >> >> The change itself is not that scary, but just reading this commitlog I >> fail to see the impact for an application. >> Can you share some light? >> > > As far as I can tell there is no impact on any applications.  The old > code, which walked through the list in a forward direction, worked > perfectly well with testpmd and DPDK pktgen applications on Power systems. > > With the ifdef fixed, the core walks the list in the reverse direction > as intended, the code still worked (i.e. no errors or problems were > observed in the same test applications). > > I'm not completely familiar with why memseg lists must be traversed in > the reverse direction for Power systems.  It might be something specific > to Power 8 systems which I'm not actually supporting on DPDK, only the > Power 9 systems that I use for for development and testing. > > Dave > If the code makes no difference anyway, should we just take it out so? -- Thanks, Anatoly