[dpdk-dev] [PATCH v6 8/9] ip_pipeline: fix lcore mapping for varying SMT threads as in ppc64

Dumitrescu, Cristian cristian.dumitrescu at intel.com
Wed Aug 31 19:33:35 CEST 2016



> -----Original Message-----
> From: Gowrishankar Muthukrishnan
> [mailto:gowrishankar.m at linux.vnet.ibm.com]
> Sent: Tuesday, August 16, 2016 11:28 AM
> To: dev at dpdk.org
> Cc: Chao Zhu <chaozhu at linux.vnet.ibm.com>; Richardson, Bruce
> <bruce.richardson at intel.com>; Ananyev, Konstantin
> <konstantin.ananyev at intel.com>; Thomas Monjalon
> <thomas.monjalon at 6wind.com>; Dumitrescu, Cristian
> <cristian.dumitrescu at intel.com>; Pradeep <pradeep at us.ibm.com>
> Subject: [PATCH v6 8/9] ip_pipeline: fix lcore mapping for varying SMT
> threads as in ppc64
> 
> 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<LCORE_NUM>/topology/physical_package_id
>   /sys/devices/system/cpu/cpu<LCORE_NUM>/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=off 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.
> 
> Signed-off-by: Gowrishankar Muthukrishnan
> <gowrishankar.m at linux.vnet.ibm.com>
> ---
>  examples/ip_pipeline/cpu_core_map.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> 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 =
> 
> 	cpu_core_map_get_socket_id_linux(lcore_id);
> 
> +#if !defined(RTE_ARCH_PPC_64)
>  			if (lcore_socket_id < 0)
>  				return -1;
> +#endif
> 
>  			if (((uint32_t) lcore_socket_id) == 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);
> 
> +#if !defined(RTE_ARCH_PPC_64)
>  				if (lcore_socket_id < 0)
>  					return -1;
> 
> @@ -377,9 +380,14 @@ cpu_core_map_compute_linux(struct
> cpu_core_map *map)
> 
>  				if (lcore_core_id < 0)
>  					return -1;
> +#endif
> 
> +#if !defined(RTE_ARCH_PPC_64)
>  				if (((uint32_t) lcore_socket_id == socket_id)
> &&
>  					((uint32_t) lcore_core_id ==
> core_id)) {
> +#else
> +				if (((uint32_t) lcore_socket_id == socket_id))
> {
> +#endif
>  					uint32_t pos =
> 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 <cristian.dumitrescu at intel.com>



More information about the dev mailing list