From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id BF6422BCC for ; Mon, 29 Feb 2016 02:50:43 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP; 28 Feb 2016 17:50:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,518,1449561600"; d="scan'208";a="913132879" Received: from shwdeisgchi083.ccr.corp.intel.com (HELO [10.239.67.193]) ([10.239.67.193]) by fmsmga001.fm.intel.com with ESMTP; 28 Feb 2016 17:50:28 -0800 To: Thomas Monjalon References: <1453661393-85704-1-git-send-email-jianfeng.tan@intel.com> <1454066522-80045-1-git-send-email-jianfeng.tan@intel.com> <2119610.dqEXMAUdDm@xps13> From: "Tan, Jianfeng" Message-ID: <56D3A3E3.1090807@intel.com> Date: Mon, 29 Feb 2016 09:50:27 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <2119610.dqEXMAUdDm@xps13> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH] eal: make resource initialization more robust 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: Mon, 29 Feb 2016 01:50:44 -0000 Hi Thomas, On 2/29/2016 5:12 AM, Thomas Monjalon wrote: > Hi, > > 2016-01-29 19:22, Jianfeng Tan: >> Current issue: DPDK is not that friendly to container environment, which >> caused by that it pre-alloc resource like cores and hugepages. But there >> are this or that resource limitations, for examples, cgroup, rlimit, >> cpuset, etc. >> >> For cores, this patch makes use of pthread_getaffinity_np to further >> narrow down detected cores before parsing coremask (-c), corelist (-l), >> and coremap (--lcores). >> >> For hugepages, this patch adds a recover mechanism to the case that >> there are no that many hugepages can be used. It relys on a mem access >> to fault-in hugepages, and if fails with SIGBUS, recover to previously >> saved stack environment with siglongjmp(). > They are some interesting ideas. > However, I am not sure a library should try to be so smart silently. > It needs more feedback to decide wether it can be the default behaviour > or an option. > > Please send coremask and hugepage mapping as separate patches as they > are totally different and may be integrated separately. Good advise, thanks! I'll do it. And one more thing FYI, coremask using pthread_getaffinity_np() may have issue on some Linux versions or distros: it excludes isolcpus. This is reported by Sergio Gonzalez Monroy , and I'm still working it out. Thanks, Jianfeng > > Thanks