From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Chao Zhu" Subject: Re: [PATCH v4 3/6] ip_pipeline: fix lcore mapping for varying SMT threads as in ppc64 Date: Thu, 11 Aug 2016 18:29:03 +0800 Message-ID: <000101d1f3bb$32fefa60$98fcef20$@linux.vnet.ibm.com> References: <1470486765-2672-1-git-send-email-gowrishankar.m@linux.vnet.ibm.com> <1470486765-2672-4-git-send-email-gowrishankar.m@linux.vnet.ibm.com> <000101d1f21d$82985610$87c90230$@linux.vnet.ibm.com> <02d3d480-85cf-619f-eb92-630adb5881c3@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: "'Bruce Richardson'" , "'Konstantin Ananyev'" , "'Thomas Monjalon'" , "'Cristian Dumitrescu'" , "'Pradeep'" To: "'gowrishankar muthukrishnan'" , Return-path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by dpdk.org (Postfix) with ESMTP id 4074C5A24 for ; Thu, 11 Aug 2016 12:28:55 +0200 (CEST) Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u7BAOB3l090667 for ; Thu, 11 Aug 2016 06:28:54 -0400 Received: from e23smtp09.au.ibm.com (e23smtp09.au.ibm.com [202.81.31.142]) by mx0a-001b2d01.pphosted.com with ESMTP id 24rmj6ffm5-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 11 Aug 2016 06:28:54 -0400 Received: from localhost by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 11 Aug 2016 20:28:51 +1000 Received: from d23relay07.au.ibm.com (d23relay07.au.ibm.com [9.190.26.37]) by d23dlp01.au.ibm.com (Postfix) with ESMTP id 06FF72CE8057 for ; Thu, 11 Aug 2016 20:28:50 +1000 (EST) Received: from d23av05.au.ibm.com (d23av05.au.ibm.com [9.190.234.119]) by d23relay07.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u7BASoDM19202070 for ; Thu, 11 Aug 2016 20:28:50 +1000 Received: from d23av05.au.ibm.com (localhost [127.0.0.1]) by d23av05.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u7BASnUt029135 for ; Thu, 11 Aug 2016 20:28:49 +1000 In-Reply-To: <02d3d480-85cf-619f-eb92-630adb5881c3@linux.vnet.ibm.com> Content-Language: zh-cn List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Gowrishankar, Thanks for the detail. If my understanding is correct, Power8 has different chips. Some of the = OpenPOWER chips have 8 cores per socket. And the max threads per core is = 8. Should we support this in cpu_core_map_init()? Here's a dump from the OpenPOWER system. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D # lscpu Architecture: ppc64le Byte Order: Little Endian CPU(s): 64 On-line CPU(s) list: 0,8,16,24,32,40,48,56 Off-line CPU(s) list: 1-7,9-15,17-23,25-31,33-39,41-47,49-55,57-63 Thread(s) per core: 1 Core(s) per socket: 8 Socket(s): 1 NUMA node(s): 1 Model: unknown L1d cache: 64K L1i cache: 32K L2 cache: 512K L3 cache: 8192K NUMA node0 CPU(s): 0,8,16,24,32,40,48,56 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > +#if defined(RTE_ARCH_PPC_64) > + app->core_map =3D cpu_core_map_init(2, 5, 1, 0); #else > > This value seems quite strange. Can you give more detail? > > app->core_map =3D cpu_core_map_init(4, 32, 4, 0); > +#endif -----Original Message----- From: gowrishankar muthukrishnan = [mailto:gowrishankar.m@linux.vnet.ibm.com]=20 Sent: 2016=E5=B9=B48=E6=9C=889=E6=97=A5 19:14 To: Chao Zhu ; dev@dpdk.org Cc: 'Bruce Richardson' ; 'Konstantin = Ananyev' ; 'Thomas Monjalon' = ; 'Cristian Dumitrescu' = ; 'Pradeep' Subject: Re: [PATCH v4 3/6] ip_pipeline: fix lcore mapping for varying = SMT threads as in ppc64 Hi Chao, Sure. Please find below one. This patch fixes ip_pipeline panic in app_init_core_map while preparing = cpu core map in powerpc with SMT off. cpu_core_map_compute_linux = currently prepares core mapping based on file existence in sysfs ie. /sys/devices/system/cpu/cpu/topology/physical_package_id /sys/devices/system/cpu/cpu/topology/core_id 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 = further continue preparing map for other online lcores instead of = returning with -1 for a first unavailable lcore. Also, in SMT=3Doff scenario for powerpc, lcore ids can not be always = indexed 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 = with indexing lcore number before positioning lcore map array. Thanks, Gowrishankar On Tuesday 09 August 2016 02:37 PM, Chao Zhu wrote: > Gowrishankar, > > Can you give more description about this patch? > Thank you! > > -----Original Message----- > From: Gowrishankar Muthukrishnan=20 > [mailto:gowrishankar.m@linux.vnet.ibm.com] > Sent: 2016=E5=B9=B48=E6=9C=886=E6=97=A5 20:33 > To: dev@dpdk.org > Cc: Chao Zhu ; Bruce Richardson=20 > ; Konstantin Ananyev=20 > ; Thomas Monjalon=20 > ; Cristian Dumitrescu=20 > ; Pradeep ;=20 > gowrishankar > Subject: [PATCH v4 3/6] ip_pipeline: fix lcore mapping for varying SMT = > threads as in ppc64 > > From: gowrishankar > > offline lcore would still refer to original core id and this has to be = > considered while creating cpu core mask. > > Signed-off-by: Gowrishankar > --- > config/defconfig_ppc_64-power8-linuxapp-gcc | 3 --- > examples/ip_pipeline/cpu_core_map.c | 12 +----------- > examples/ip_pipeline/init.c | 4 ++++ > 3 files changed, 5 insertions(+), 14 deletions(-) > > diff --git a/config/defconfig_ppc_64-power8-linuxapp-gcc > b/config/defconfig_ppc_64-power8-linuxapp-gcc > index dede34f..a084672 100644 > --- a/config/defconfig_ppc_64-power8-linuxapp-gcc > +++ b/config/defconfig_ppc_64-power8-linuxapp-gcc > @@ -58,6 +58,3 @@ CONFIG_RTE_LIBRTE_FM10K_PMD=3Dn > > # This following libraries are not available on Power. So they're=20 > turned off. > CONFIG_RTE_LIBRTE_SCHED=3Dn > -CONFIG_RTE_LIBRTE_PORT=3Dn > -CONFIG_RTE_LIBRTE_TABLE=3Dn > -CONFIG_RTE_LIBRTE_PIPELINE=3Dn > diff --git a/examples/ip_pipeline/cpu_core_map.c > b/examples/ip_pipeline/cpu_core_map.c > index cb088b1..482e68e 100644 > --- a/examples/ip_pipeline/cpu_core_map.c > +++ b/examples/ip_pipeline/cpu_core_map.c > @@ -351,9 +351,6 @@ cpu_core_map_compute_linux(struct cpu_core_map = *map) > int lcore_socket_id =3D > cpu_core_map_get_socket_id_linux(lcore_id); > > - if (lcore_socket_id < 0) > - return -1; > - > if (((uint32_t) lcore_socket_id) =3D=3D socket_id) > n_detected++; > } > @@ -368,18 +365,11 @@ cpu_core_map_compute_linux(struct cpu_core_map = *map) > cpu_core_map_get_socket_id_linux( > lcore_id); > > - if (lcore_socket_id < 0) > - return -1; > - > Why to remove the lcore_socket_id check? > > int lcore_core_id =3D > cpu_core_map_get_core_id_linux( > lcore_id); > > - if (lcore_core_id < 0) > - return -1; > - > - if (((uint32_t) lcore_socket_id =3D=3D > socket_id) && > - ((uint32_t) lcore_core_id =3D=3D > core_id)) { > + if ((uint32_t) lcore_socket_id =3D=3D socket_id) > { > uint32_t pos =3D cpu_core_map_pos(map, > socket_id, > core_id_contig, > diff --git a/examples/ip_pipeline/init.c b/examples/ip_pipeline/init.c = > index cd167f6..60c931f 100644 > --- a/examples/ip_pipeline/init.c > +++ b/examples/ip_pipeline/init.c > @@ -61,7 +61,11 @@ static void > app_init_core_map(struct app_params *app) { > APP_LOG(app, HIGH, "Initializing CPU core map ..."); > +#if defined(RTE_ARCH_PPC_64) > + app->core_map =3D cpu_core_map_init(2, 5, 1, 0); #else > > This value seems quite strange. Can you give more detail? > > app->core_map =3D cpu_core_map_init(4, 32, 4, 0); > +#endif > > if (app->core_map =3D=3D NULL) > rte_panic("Cannot create CPU core map\n"); > -- > 1.9.1 > > >