From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 27FB15962 for ; Tue, 2 Aug 2016 10:25:21 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP; 02 Aug 2016 01:24:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,459,1464678000"; d="scan'208";a="743007752" Received: from pgsmsx106.gar.corp.intel.com ([10.221.44.98]) by FMSMGA003.fm.intel.com with ESMTP; 02 Aug 2016 01:24:49 -0700 Received: from pgsmsx110.gar.corp.intel.com (10.221.44.111) by PGSMSX106.gar.corp.intel.com (10.221.44.98) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 2 Aug 2016 16:22:30 +0800 Received: from pgsmsx106.gar.corp.intel.com ([169.254.9.132]) by PGSMSX110.gar.corp.intel.com ([10.221.44.111]) with mapi id 14.03.0248.002; Tue, 2 Aug 2016 16:22:30 +0800 From: "Dai, Wei" To: Thomas Monjalon CC: "dev@dpdk.org" , "Yigit, Ferruh" , "adambynes@outlook.com" , "Liang, Cunming" Thread-Topic: [dpdk-dev] [PATCH v3 4/4] eal: fix end character check in --lcores argument Thread-Index: AQHR5/okfLJOx+nT0U+wl5EZcjOqhaAtctOAgAAK74CAB9G7MA== Date: Tue, 2 Aug 2016 08:22:29 +0000 Message-ID: <49759EB36A64CF4892C1AFEC9231E8D63A268522@PGSMSX106.gar.corp.intel.com> References: <1469081018-55300-1-git-send-email-wei.dai@intel.com> <1469618870-144592-1-git-send-email-wei.dai@intel.com> <579A2433.1060701@intel.com> <1717702.2SVR8RdYDI@xps13> In-Reply-To: <1717702.2SVR8RdYDI@xps13> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZWI5YjM5NzItNzQ2MS00ZDlhLTgzZDktZjRlNjNmMTRhMmY1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ilp3TlhEdkdtcm5JakUyS1NXVHh0WW5ySlV0cXpkYkRYdG9wQmQ1WkJ2UUU9In0= x-ctpclassification: CTP_IC x-originating-ip: [172.30.20.205] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v3 4/4] eal: fix end character check in --lcores argument 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: Tue, 02 Aug 2016 08:25:21 -0000 Hi, Thomas, Yigit > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Friday, July 29, 2016 12:06 AM > To: Dai, Wei > Cc: dev@dpdk.org; Yigit, Ferruh > Subject: Re: [dpdk-dev] [PATCH v3 4/4] eal: fix end character check in --= lcores > argument >=20 > 2016-07-28 16:26, Ferruh Yigit: > > On 7/27/2016 12:27 PM, Wei Dai wrote: > > > With --lcores 'a-b@c-d', eal_parse_cores() fails because > > > eal_parse_set() fails due to the next character after lcore set a-b, > > > which is '@'and not ',' or '\0'. > > > There is also a right check immediately after this incorrect check. > > > > > > Fixes: 53e54bf81700 ("eal: new option --lcores for cpu assignment") > > > > > > Signed-off-by: Wei Dai > > > > I am not sure if a-b@c-d syntax should be supported. (a-b)@(c-d) is > > supported and already working. >=20 > Agreed. >=20 > Series applied, except this last patch 4, thanks Sorry, I can't find any document to clarify whether a-b@c-d shoule be suppo= rted. So I design following case to verify all kinds of combination of - and @.=20 I tested my patch with --lcores '0-3@12-15, 4-7@(8-11), (8-11)@4-7, (12-15= )@(0-3), 16-19, (20-23) ', After calling eal_parse_args(argc, argv), I observed lcore_config[i].cpuse= t to check cpuset of each lcore. I added following codes immediately after calling fctret =3D eal_parse_args= (argc, argv); in function rte_eal_init( ) in eal.c to check this patch. { struct rte_config *p; const char *rte_role_str[2] =3D {"ROLE_RTE", "ROLE_OFF"}; p =3D rte_eal_get_configuration(); for (i=3D0; i<28; i++) { printf("lcore %2d status =3D %s, runs on cpuset =3D 0x%08lX\n",=20 i, rte_role_str[p->lcore_role[i]], lcore_config[i].cpuset.__bits[0]); } } The result is as follow: lcore 0 status =3D ROLE_RTE, runs on cpuset =3D 0x0000F000 lcore 1 status =3D ROLE_RTE, runs on cpuset =3D 0x0000F000 lcore 2 status =3D ROLE_RTE, runs on cpuset =3D 0x0000F000 lcore 3 status =3D ROLE_RTE, runs on cpuset =3D 0x0000F000 lcore 4 status =3D ROLE_RTE, runs on cpuset =3D 0x00000F00 lcore 5 status =3D ROLE_RTE, runs on cpuset =3D 0x00000F00 lcore 6 status =3D ROLE_RTE, runs on cpuset =3D 0x00000F00 lcore 7 status =3D ROLE_RTE, runs on cpuset =3D 0x00000F00 lcore 8 status =3D ROLE_RTE, runs on cpuset =3D 0x000000F0 lcore 9 status =3D ROLE_RTE, runs on cpuset =3D 0x000000F0 lcore 10 status =3D ROLE_RTE, runs on cpuset =3D 0x000000F0 lcore 11 status =3D ROLE_RTE, runs on cpuset =3D 0x000000F0 lcore 12 status =3D ROLE_RTE, runs on cpuset =3D 0x0000000F lcore 13 status =3D ROLE_RTE, runs on cpuset =3D 0x0000000F lcore 14 status =3D ROLE_RTE, runs on cpuset =3D 0x0000000F lcore 15 status =3D ROLE_RTE, runs on cpuset =3D 0x0000000F lcore 16 status =3D ROLE_RTE, runs on cpuset =3D 0x00010000 lcore 17 status =3D ROLE_RTE, runs on cpuset =3D 0x00020000 lcore 18 status =3D ROLE_RTE, runs on cpuset =3D 0x00040000 lcore 19 status =3D ROLE_RTE, runs on cpuset =3D 0x00080000 lcore 20 status =3D ROLE_RTE, runs on cpuset =3D 0x00F00000 lcore 21 status =3D ROLE_RTE, runs on cpuset =3D 0x00F00000 lcore 22 status =3D ROLE_RTE, runs on cpuset =3D 0x00F00000 lcore 23 status =3D ROLE_RTE, runs on cpuset =3D 0x00F00000 lcore 24 status =3D ROLE_OFF, runs on cpuset =3D 0x00000000 lcore 25 status =3D ROLE_OFF, runs on cpuset =3D 0x00000000 lcore 26 status =3D ROLE_OFF, runs on cpuset =3D 0x00000000 lcore 27 status =3D ROLE_OFF, runs on cpuset =3D 0x00000000 =09