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=-0.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 11BB1C34047 for ; Wed, 19 Feb 2020 11:16:27 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 8DAE42067D for ; Wed, 19 Feb 2020 11:16:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="AW1tI4X7" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8DAE42067D Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.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 4E57034F3; Wed, 19 Feb 2020 12:16:24 +0100 (CET) Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by dpdk.org (Postfix) with ESMTP id B311F25B3 for ; Wed, 19 Feb 2020 12:16:22 +0100 (CET) Received: by mail-wm1-f43.google.com with SMTP id c84so179136wme.4 for ; Wed, 19 Feb 2020 03:16:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lHB1ND5bwyLb14mhWxqscJs0ufkEwJwnihaLggVAHEQ=; b=AW1tI4X7JugEeH6Si4AV6Zav18iKt+Wp3MX9I8ShCYzPhzEXR2vsw0hM8Ny/lVskfj yQ2sIzWDS0nOdc2znpEVK+/7741dxy8PI4wIc8VRjs+IeHvlLhmlUvJ/kaDw4ORMhAxA Cc2h7pb+ZrjmpzFjhABrjeqJX1wkLVCNEdWmjZjQ5ZynhUlp1dEDJHR7VFsHz9xc3fz2 /pauHnKelaOjsncMKKLQauWKgyRoM/3ERBs1hLzhu1kROJGWyQP0GVMXDEabxtl0RLqk EF9aSPIY3PHVOmRD2z+mFRNQRr4nUcWQQ84pvH9H2i3wvB0WjOuYgoX+H0/1vGDyTIkw Xnyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lHB1ND5bwyLb14mhWxqscJs0ufkEwJwnihaLggVAHEQ=; b=hAEntNi+KOwG06J5a79fHWn8kvmJQxbBAAuHVLvR4TrQ4vEGdhMI8oJQpgtzDaRGyw vZ276squkSFIBG9fjhsPoJwovR71hQWeI6nk9QTOZ9cNMOsWZTyxx7Mv/uYA5Or0JEcS hZzidmkKsVGL+ZitF+ctLj9n0nE5uayXfWLYYNQbPAOTEh8EB8/l0B+dGEObEu9ZZz3T 9jf3TeMhAixxB5nXAYEgTY+Pk96Nd/aBtZDhBBpCeU93h4cE67293A02fH93E+LX6Hm6 Wi76UqZHzzTbvNNJ3tjL6K5zFSNEW2PN9kdUx5VVwYmGM/fMaA6VrohrmI9FoGd5w4yR e9+Q== X-Gm-Message-State: APjAAAUZr7lqn/3iwkJ2Yq7BfBGYytVl1Ai/ftbRiSvjLpqAdOpsPgcN 3IZGxGF4ub2O8FxFYceuyh3Ho3DvyUygY1w8JG8= X-Google-Smtp-Source: APXvYqz3pAEVcjBprBXEM3VJVbOjkgM0YpvIU2ylKkJQfeDYv5BuMMbNap7Tlk65SlLegygHQk/8+wVGCpuwiJMO4n8= X-Received: by 2002:a1c:cc06:: with SMTP id h6mr9722966wmb.118.1582110982053; Wed, 19 Feb 2020 03:16:22 -0800 (PST) MIME-Version: 1.0 References: <5192f94a-e50a-7e61-2e33-a218a4b6b5b4@intel.com> <9c888eb0-2192-137c-da5c-97f30da5204a@intel.com> In-Reply-To: From: Kamaraj P Date: Wed, 19 Feb 2020 16:46:10 +0530 Message-ID: To: Kevin Traynor Cc: "Burakov, Anatoly" , dev@dpdk.org, Nageswara Rao Penumarthy , "Kamaraj P (kamp)" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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" Hi Kevin/Anatoly, Yes we have the patch already included in our code base. Looks like it get struck in the below piece of the code: mapped_addr = mmap(requested_addr, (size_t)map_sz, PROT_READ, mmap_flags, -1, 0); Could you please share your thoughts on this? Thanks, Kamaraj On Wed, Feb 19, 2020 at 4:26 PM Kevin Traynor wrote: > On 19/02/2020 10:23, Burakov, Anatoly wrote: > > On 17-Feb-20 9:57 AM, Kamaraj P wrote: > >> Hi Anatoly, > >> Thanks for the clarifications. > >> > >> Currently we are migrating to the new DPDK 18.11 ( from 17.05). Here > is > >> our configuration: > >> ======================================================================= > >> We have configured the "--legacy-mem" option and changed the > >> CONFIG_RTE_MAX_MEM_MB to 2048 (and we are passing 2MB huge page 188 and > >> no 1G hugepages in the bootargs). > >> Our application deployment as 2G RAM > >> ======================================================================= > >> We are observing the hang issue, with above configuration. > >> Please see the below logs: > >> EAL: Detected lcore 0 as core 0 on socket 0 > >> EAL: Support maximum 128 logical core(s) by configuration. > >> EAL: Detected 1 lcore(s) > >> EAL: Detected 1 NUMA nodes > >> EAL: open shared lib /usr/lib64/librte_pmd_ixgbe.so.2.1 > >> EAL: open shared lib /usr/lib64/librte_pmd_e1000.so.1.1 > >> EAL: Multi-process socket /var/run/dpdk/rte/mp_socket > >> EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or > >> directory) > >> EAL: VFIO PCI modules not loaded > >> EAL: No free hugepages reported in hugepages-1048576kB > >> EAL: No free hugepages reported in hugepages-1048576kB > >> EAL: Probing VFIO support... > >> EAL: Module /sys/module/vfio not found! error 2 (No such file or > directory) > >> EAL: VFIO modules not loaded, skipping VFIO support... > >> EAL: Ask a virtual area of 0x2e000 bytes > >> EAL: Virtual area found at 0x100000000 (size = 0x2e000) > >> EAL: Setting up physically contiguous memory... > >> EAL: Setting maximum number of open files to 4096 > >> EAL: Detected memory type: socket_id:0 hugepage_sz:1073741824 > >> EAL: Detected memory type: socket_id:0 hugepage_sz:2097152 > >> EAL: Creating 1 segment lists: n_segs:1 socket_id:0 > hugepage_sz:1073741824 > >> EAL: Ask a virtual area of 0x1000 bytes > >> EAL: Virtual area found at 0x10002e000 (size = 0x1000) > >> EAL: Memseg list allocated: 0x100000kB at socket 0 > >> EAL: Ask a virtual area of 0x40000000 bytes > >> <<< --- struck here ---> >>>> > >> > >> > >> Is there any other dpdk options thro which we can resolve the above > >> issue ? Any thoughts ? > >> Like passing the *--socket-limit* and *--m *parameter etc during the > EAL > >> Init (could help ???). > >> Please suggest us. > >> > > > > It sounds like it hangs in eal_get_virtual_area() - we've had a similar > > issue before, not sure if the fix was backported to 18.11. Is this patch > > present in your code? > > > > http://patches.dpdk.org/patch/51943/ > > > > In 18.11 LTS releases since v18.11.2. Current release is v18.11.6. > > commit 558509fbb2b0a0f5803f348634e4956ff8cb5214 > Author: Shahaf Shuler > Date: Sun Mar 31 11:43:48 2019 +0300 > > mem: limit use of address hint > > [ upstream commit 237060c4ad15b4ee9002be3c0e56ac3070eceb48 ] > > > If not, it would be of great help if you could find the exact spot where > > the hang happens. > > > > > > >