From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98445C11D09 for ; Thu, 20 Feb 2020 10:02:20 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 53AC324672 for ; Thu, 20 Feb 2020 10:02:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 53AC324672 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AB1651BFA1; Thu, 20 Feb 2020 11:02:19 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 4271E1BFA0 for ; Thu, 20 Feb 2020 11:02:17 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2020 02:02:17 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,464,1574150400"; d="scan'208";a="315689606" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.130]) ([10.237.220.130]) by orsmga001.jf.intel.com with ESMTP; 20 Feb 2020 02:02:15 -0800 To: Kamaraj P Cc: Kevin Traynor , dev@dpdk.org, Nageswara Rao Penumarthy , "Kamaraj P (kamp)" , mtang2@cisco.com References: <5192f94a-e50a-7e61-2e33-a218a4b6b5b4@intel.com> <9c888eb0-2192-137c-da5c-97f30da5204a@intel.com> <56527d9f-b079-a580-4a80-2207c1822260@intel.com> <0792d8b5-b0fd-15c8-f0ce-99a113c4c603@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Thu, 20 Feb 2020 10:02:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.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] CONFIG_RTE_MAX_MEM_MB fails in DPDK18.05 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 19-Feb-20 4:20 PM, Kamaraj P wrote: > Hi Anatoly, > > Yes we are facing an issue with our custom applications. > Earlier we have tried with l2fwd DPDK application and does not see any > issue with memory initialization. > Not sure whether we missed any other options. > > BTW when we tried with l2fwd application, the application does not seem > to hang during the memory initialization where as our application is > kind of struck when getting memory. > Do we tune any config parameters from DPDK ? > Please advise. > Hi, This doesn't look like an issue that is with DPDK. It is more likely that something else triggers this (similar to mlockall()). Are you sure there are no more mem lock calls anywhere in your application before EAL init (i.e. inside the libraries you use, etc.)? Because so far, page pinning is the only thing i can think of that would cause this sort of behavior. -- Thanks, Anatoly