From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <cristian.dumitrescu@intel.com>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by dpdk.org (Postfix) with ESMTP id D1D692BD2
 for <dev@dpdk.org>; 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" <cristian.dumitrescu@intel.com>
To: Gowrishankar Muthukrishnan <gowrishankar.m@linux.vnet.ibm.com>,
 "dev@dpdk.org" <dev@dpdk.org>
CC: Chao Zhu <chaozhu@linux.vnet.ibm.com>, "Richardson, Bruce"
 <bruce.richardson@intel.com>, "Ananyev, Konstantin"
 <konstantin.ananyev@intel.com>, Thomas Monjalon <thomas.monjalon@6wind.com>,
 Pradeep <pradeep@us.ibm.com>
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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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 <chaozhu@linux.vnet.ibm.com>; Richardson, Bruce
> <bruce.richardson@intel.com>; Ananyev, Konstantin
> <konstantin.ananyev@intel.com>; Thomas Monjalon
> <thomas.monjalon@6wind.com>; Dumitrescu, Cristian
> <cristian.dumitrescu@intel.com>; Pradeep <pradeep@us.ibm.com>
> 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<LCORE_NUM>/topology/physical_package_id
>   /sys/devices/system/cpu/cpu<LCORE_NUM>/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
> <gowrishankar.m@linux.vnet.ibm.com>
> ---
>  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 <cristian.dumitrescu@intel.com>