From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id D1D692BD2 for ; Wed, 31 Aug 2016 19:33:38 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 31 Aug 2016 10:33:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.30,263,1470726000"; d="scan'208";a="1049764249" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by fmsmga002.fm.intel.com with ESMTP; 31 Aug 2016 10:33:37 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.71]) by IRSMSX106.ger.corp.intel.com ([169.254.8.240]) with mapi id 14.03.0248.002; Wed, 31 Aug 2016 18:33:35 +0100 From: "Dumitrescu, Cristian" To: Gowrishankar Muthukrishnan , "dev@dpdk.org" CC: Chao Zhu , "Richardson, Bruce" , "Ananyev, Konstantin" , Thomas Monjalon , Pradeep Thread-Topic: [PATCH v6 8/9] ip_pipeline: fix lcore mapping for varying SMT threads as in ppc64 Thread-Index: AQHR96j6n02Y8s+JTUKNZpe1w6k39KBja1cQ Date: Wed, 31 Aug 2016 17:33:35 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D8912647A547E4@IRSMSX108.ger.corp.intel.com> References: <1471343279-24014-1-git-send-email-gowrishankar.m@linux.vnet.ibm.com> <1471343279-24014-9-git-send-email-gowrishankar.m@linux.vnet.ibm.com> In-Reply-To: <1471343279-24014-9-git-send-email-gowrishankar.m@linux.vnet.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMDMzODAxOTktNTdiZS00YzgzLTllOWQtNjgzYjZmM2FkNzBkIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX1BVQkxJQyJ9XX1dfSwiU3ViamVjdExhYmVscyI6W10sIlRNQ1ZlcnNpb24iOiIxNS45LjYuNiIsIlRydXN0ZWRMYWJlbEhhc2giOiJBK2l1ZUZmZHd0WW41bEFvTzUwdUNkXC9Nc2lzb3Y0Q2UrSDJCbEFRQlJITT0ifQ== x-ctpclassification: CTP_PUBLIC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v6 8/9] ip_pipeline: fix lcore mapping for varying SMT threads as in ppc64 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 17:33:39 -0000 > -----Original Message----- > From: Gowrishankar Muthukrishnan > [mailto:gowrishankar.m@linux.vnet.ibm.com] > Sent: Tuesday, August 16, 2016 11:28 AM > To: dev@dpdk.org > Cc: Chao Zhu ; Richardson, Bruce > ; Ananyev, Konstantin > ; Thomas Monjalon > ; Dumitrescu, Cristian > ; Pradeep > Subject: [PATCH v6 8/9] ip_pipeline: fix lcore mapping for varying SMT > threads as in ppc64 >=20 > This patch fixes ip_pipeline panic in app_init_core_map while preparing c= pu > core map in powerpc with SMT off. cpu_core_map_compute_linux currently > prepares > core mapping based on file existence in sysfs ie. >=20 > /sys/devices/system/cpu/cpu/topology/physical_package_id > /sys/devices/system/cpu/cpu/topology/core_id >=20 > These files do not exist for lcores which are offline for any reason (as = in > powerpc, while SMT is off). In this situation, this function should furth= er > continue preparing map for other online lcores instead of returning with = -1 > for a first unavailable lcore. >=20 > Also, in SMT=3Doff scenario for powerpc, lcore ids can not be always inde= xed > from > 0 upto 'number of cores present' (/sys/devices/system/cpu/present). For > eg, for > an online lcore 32, core_id returned in sysfs is 112 where online lcores = are > 10 (as in one configuration), hence sysfs lcore id can not be checked wit= h > indexing lcore number before positioning lcore map array. >=20 > Signed-off-by: Gowrishankar Muthukrishnan > > --- > examples/ip_pipeline/cpu_core_map.c | 8 ++++++++ > 1 file changed, 8 insertions(+) >=20 > diff --git a/examples/ip_pipeline/cpu_core_map.c > b/examples/ip_pipeline/cpu_core_map.c > index cb088b1..dd8f678 100644 > --- a/examples/ip_pipeline/cpu_core_map.c > +++ b/examples/ip_pipeline/cpu_core_map.c > @@ -351,8 +351,10 @@ cpu_core_map_compute_linux(struct > cpu_core_map *map) > int lcore_socket_id =3D >=20 > cpu_core_map_get_socket_id_linux(lcore_id); >=20 > +#if !defined(RTE_ARCH_PPC_64) > if (lcore_socket_id < 0) > return -1; > +#endif >=20 > if (((uint32_t) lcore_socket_id) =3D=3D socket_id) > n_detected++; > @@ -368,6 +370,7 @@ cpu_core_map_compute_linux(struct cpu_core_map > *map) > cpu_core_map_get_socket_id_linux( > lcore_id); >=20 > +#if !defined(RTE_ARCH_PPC_64) > if (lcore_socket_id < 0) > return -1; >=20 > @@ -377,9 +380,14 @@ cpu_core_map_compute_linux(struct > cpu_core_map *map) >=20 > if (lcore_core_id < 0) > return -1; > +#endif >=20 > +#if !defined(RTE_ARCH_PPC_64) > if (((uint32_t) lcore_socket_id =3D=3D socket_id) > && > ((uint32_t) lcore_core_id =3D=3D > core_id)) { > +#else > + if (((uint32_t) lcore_socket_id =3D=3D socket_id)) > { > +#endif > uint32_t pos =3D > cpu_core_map_pos(map, > socket_id, > core_id_contig, > -- > 1.9.1 This patch only changes the code for PPC CPUs, I don't have the hardware to= check it myself, but I will take Gowrishankar's and Chao's word it is the = right thing to do for PPC CPUs, so ... Acked by: Cristian Dumitrescu