From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 72D135A69 for ; Tue, 26 Jan 2016 03:22:21 +0100 (CET) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga101.fm.intel.com with ESMTP; 25 Jan 2016 18:22:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,347,1449561600"; d="scan'208";a="36142308" Received: from shwdeisgchi083.ccr.corp.intel.com (HELO [10.239.67.119]) ([10.239.67.119]) by fmsmga004.fm.intel.com with ESMTP; 25 Jan 2016 18:22:19 -0800 To: Neil Horman References: <1453661393-85704-1-git-send-email-jianfeng.tan@intel.com> <20160125134636.GA29690@hmsreliant.think-freely.org> From: "Tan, Jianfeng" Message-ID: <56A6D85A.6030400@intel.com> Date: Tue, 26 Jan 2016 10:22:18 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160125134636.GA29690@hmsreliant.think-freely.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, yuanhan.liu@intel.com Subject: Re: [dpdk-dev] [RFC] eal: add cgroup-aware resource self discovery 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, 26 Jan 2016 02:22:21 -0000 Hi Neil, On 1/25/2016 9:46 PM, Neil Horman wrote: > On Mon, Jan 25, 2016 at 02:49:53AM +0800, Jianfeng Tan wrote: ... >> -- >> 2.1.4 >> >> > > This doesn't make a whole lot of sense, for several reasons: > > 1) Applications, as a general rule shouldn't be interrogating the cgroups > interface at all. The main reason to do this in DPDK is that DPDK obtains resource information from sysfs and proc, which are not well containerized so far. And DPDK pre-allocates resource instead of on-demand gradual allocating. > > 2) Cgroups aren't the only way in which a cpuset or memoryset can be restricted > (the isolcpus command line argument, or a taskset on a parent process for > instance, but there are several others). Yes, I agree. To enable that, I'd like design the new API for resource self discovery in a flexible way. A parameter "type" is used to specify the solution to discovery way. In addition, I'm considering to add a callback function pointer so that users can write their own resource discovery functions. > > Instead of trying to figure out what cpuset is valid for your process by > interrogating the cgroups heirarchy, instead you should follow the proscribed > method of calling sched_getaffinity after calling sched_setaffinity. That will > give you the canonical cpuset that you are executing on, taking all cpuset > filters into account (including cgroups and any other restrictions). Its far > simpler as well, as it doesn't require a ton of file/string processing. Yes, this way is much better for cpuset discovery. But is there such a syscall for hugepages? Thanks, Jianfeng > > Neil >