From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 9AFA19AC2 for ; Wed, 25 Feb 2015 02:25:22 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga102.jf.intel.com with ESMTP; 24 Feb 2015 17:21:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,642,1418112000"; d="scan'208";a="532409704" Received: from pgsmsx107.gar.corp.intel.com ([10.221.44.105]) by orsmga003.jf.intel.com with ESMTP; 24 Feb 2015 17:16:14 -0800 Received: from kmsmsx154.gar.corp.intel.com (172.21.73.14) by PGSMSX107.gar.corp.intel.com (10.221.44.105) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 25 Feb 2015 09:25:17 +0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.110.14) by KMSMSX154.gar.corp.intel.com (172.21.73.14) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 25 Feb 2015 09:25:16 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.62]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.197]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 09:25:09 +0800 From: "Liang, Cunming" To: Thomas Monjalon Thread-Topic: [PATCH v8 00/19] support multi-pthread per core Thread-Index: AQHQSlaoik+1C1IdiEmr65cChneSgZz0G50AgAuP1YCAAOweMA== Date: Wed, 25 Feb 2015 01:25:09 +0000 Message-ID: References: <1423970145-31985-1-git-send-email-cunming.liang@intel.com> <1424138896-28618-1-git-send-email-cunming.liang@intel.com> <2601191342CEEE43887BDE71AB977258213EE0A9@irsmsx105.ger.corp.intel.com> <2206208.RNY87Zy52I@xps13> In-Reply-To: <2206208.RNY87Zy52I@xps13> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v8 00/19] support multi-pthread per core 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, 25 Feb 2015 01:25:23 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Wednesday, February 25, 2015 2:53 AM > To: Liang, Cunming > Cc: Ananyev, Konstantin; dev@dpdk.org; olivier.matz@6wind.com; > nhorman@tuxdriver.com > Subject: Re: [PATCH v8 00/19] support multi-pthread per core >=20 > > > v8 changes: > > > keep using strlen for trusted input string > > > > > > v7 changes: > > > update EAL version map for new public EAL API > > > rollback to use strnlen() passing EAL core option > > > > > > v6 changes: > > > rename RTE_RING_PAUSE_REP(_COUNT) and set default to 0 > > > rollback to use RTE_MAX_LCORE when checking valid lcore_id for EAL = thread > > > > > > v5 changes: > > > reorder some patch and split into addtional two patches > > > rte_thread_get_affinity() return type change to avoid > > > add RTE_RING_PAUSE_REP into config and by default turn off > > > > > > v4 changes: > > > new patch fixing strnlen() invalid return in 32bit icc [03/17] > > > update and add more comments on sched_yield() [16/17] > > > > > > v3 changes: > > > new patch adding sched_yield() in rte_ring to avoid long spin [16/1= 7] > > > > > > v2 changes: > > > add '-' support for EAL option '--lcores' [02/17] > > > > > > The patch series contain the enhancements of EAL and fixes for librar= ies > > > to run multi-pthreads(either EAL or non-EAL thread) per physical core= . > > > Two major changes list as below: > > > - Extend the core affinity of each EAL thread to 1:n. > > > Each lcore stands for a EAL thread rather than a logical core. > > > The change adds new EAL option to allow static lcore to cpuset assg= inment. > > > Then a lcore(EAL thread) affinity to a cpuset, original 1:1 mapping= is the > special case. > > > - Fix the libraries to allow running on any non-EAL thread. > > > It fix the gaps running libraries in non-EAL thread(dynamic created= by user). > > > Each fix libraries take care the case of rte_lcore_id() >=3D RTE_MA= X_LCORE. > > > > > > Thanks a million for the comments from Konstantin, Bruce, Mirek and > Stephen in RFC review. > > > > > > Cunming Liang (19): > > > eal: add cpuset into per EAL thread lcore_config > > > eal: fix PAGE_SIZE redefine complaint on freebsd > > > eal: new eal option '--lcores' for cpu assignment > > > eal: fix wrong strnlen() return value in 32bit icc > > > eal: add public function parsing socket_id from cpu_id > > > eal: new TLS definition and API declaration > > > eal: add eal_common_thread.c for common thread API > > > eal: standardize init sequence between linux and bsd > > > eal: add rte_gettid() to acquire unique system tid > > > eal: apply affinity of EAL thread by assigned cpuset > > > enic: fix re-define freebsd compile complain > > > malloc: fix the issue of SOCKET_ID_ANY > > > log: fix the gap to support non-EAL thread > > > eal: set _lcore_id and _socket_id to (-1) by default > > > eal: fix recursive spinlock in non-EAL thraed > > > mempool: add support to non-EAL thread > > > ring: add support to non-EAL thread > > > ring: add sched_yield to avoid spin forever > > > timer: add support to non-EAL thread > > > > Acked-by: Konstantin Ananyev >=20 > I tried to fix many english typos. Please consider it during reviews. > Cunming, you'll repeat 10 times "non-EAL threads compute more than none" = ;) >=20 > Applied, thanks [Liang, Cunming] Thanks, Thomas. I'll take care of it next time. :) >=20 > My main concern in this patchset is about naming. Now lcore means thread > in many places. I would prefer to have a cleanup to use right term at > right place, even if it requires breaking API. [Liang, Cunming] 'lcore' is limited used as EAL thread. Comparing to the legacy usage, the difference is such lcore(logical core) m= ay not only affinity to one physical core. If extending the meaning of 'lcore' a bit wider (as prog_guide doc said, le= t's consider a logical core stands for an EAL thread), it then makes sense = to keep origin APIs. That helps the existing apps migrate transparently. >=20 > Are we going to deprecate the fresh option -l in favor of --lcores/--thre= ads? [Liang, Cunming] I think so, as '--lcores' already covered '-l' pattern. Mark it as deprecated, and remove it on next version ?