From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 5D52D1B47C for ; Thu, 7 Feb 2019 12:15:35 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2019 03:15:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,343,1544515200"; d="scan'208";a="132268176" Received: from aburakov-mobl1.ger.corp.intel.com (HELO [10.237.220.95]) ([10.237.220.95]) by orsmga002.jf.intel.com with ESMTP; 07 Feb 2019 03:15:32 -0800 To: Iain Barker , "Wiles, Keith" Cc: dev@dpdk.org, Edwin Leung References: <631579E3-02F5-4E12-8BE6-DDAC0AE2E4A7@oracle.com> <549A6EB0-6E19-460D-9BE5-52AA40003AF0@intel.com> <345EDE69-C416-405F-B88C-04EE8384D20F@oracle.com> <896AF59A-4CCF-42FE-B2D7-160C69427DD2@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Thu, 7 Feb 2019 11:15:31 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] Question about DPDK hugepage fd change X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2019 11:15:35 -0000 On 06-Feb-19 1:57 PM, Iain Barker wrote: >> Can you use 1G hugepages instead of 2M pages or a combo of the two, not sure how dpdk handles having both in the system? > > Unfortunately, no. Some of our customer deployments are tenancies on KVM hosts and low-end appliances, which are not configurable by the end user to enable 1G huge pages. > > I think we are going to have to revert this patch set from our build, as I don't see any other alternative for using DPDK 18 whilst remaining compliant to the POSIX/glibc requirements. > Yep, apologies for that. I think a new command-line flag to disable this functionality should solve the issue, but we already have enough of those... -- Thanks, Anatoly