From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 9A0E07EB4 for ; Thu, 13 Sep 2018 15:12:45 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E993D87625; Thu, 13 Sep 2018 13:12:44 +0000 (UTC) Received: from [10.36.112.13] (unknown [10.36.112.13]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2EFD6608EC; Thu, 13 Sep 2018 13:12:42 +0000 (UTC) To: Anatoly Burakov , dev@dpdk.org Cc: tiwei.bie@intel.com, ray.kinsella@intel.com, zhihong.wang@intel.com, kuralamudhan.ramakrishnan@intel.com References: <53a660ffd746c81f59fc3e1f35ac2222a7237641.1536073997.git.anatoly.burakov@intel.com> From: Maxime Coquelin Message-ID: <064c2089-c730-fccf-7cc0-579222c29fb0@redhat.com> Date: Thu, 13 Sep 2018 15:12:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <53a660ffd746c81f59fc3e1f35ac2222a7237641.1536073997.git.anatoly.burakov@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 13 Sep 2018 13:12:45 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH v3 3/9] mem: raise maximum fd limit unconditionally 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, 13 Sep 2018 13:12:45 -0000 On 09/04/2018 05:15 PM, Anatoly Burakov wrote: > Previously, when we allocated hugepages, we closed the fd's corresponding > to them after we've done our mappings. Since we did mmap(), we didn't > actually lose the reference, but file descriptors used for mmap() do not > count against the fd limit. Since we are going to store all of our fd's, > we will hit the fd limit much more often when using smaller page sizes. > > Fix this to raise the fd limit to maximum unconditionally. > > Signed-off-by: Anatoly Burakov > --- > lib/librte_eal/linuxapp/eal/eal_memory.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c > index dbf19499e..dfb537f59 100644 > --- a/lib/librte_eal/linuxapp/eal/eal_memory.c > +++ b/lib/librte_eal/linuxapp/eal/eal_memory.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -2204,6 +2205,25 @@ memseg_secondary_init(void) > int > rte_eal_memseg_init(void) > { > + /* increase rlimit to maximum */ > + struct rlimit lim; > + > + if (getrlimit(RLIMIT_NOFILE, &lim) == 0) { > + /* set limit to maximum */ > + lim.rlim_cur = lim.rlim_max; > + > + if (setrlimit(RLIMIT_NOFILE, &lim) < 0) { > + RTE_LOG(DEBUG, EAL, "Setting maximum number of open files failed: %s\n", > + strerror(errno)); > + } else { > + RTE_LOG(DEBUG, EAL, "Setting maximum number of open files to %" > + PRIu64 "\n", > + (uint64_t)lim.rlim_cur); > + } > + } else { > + RTE_LOG(ERR, EAL, "Cannot get current resource limits\n"); > + } > + > return rte_eal_process_type() == RTE_PROC_PRIMARY ? > #ifndef RTE_ARCH_64 > memseg_primary_init_32() : > Reviewed-by: Maxime Coquelin