From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 28428A0544; Fri, 23 Sep 2022 13:47:31 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1C7624003F; Fri, 23 Sep 2022 13:47:31 +0200 (CEST) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.46]) by mails.dpdk.org (Postfix) with ESMTP id 713644003C for ; Fri, 23 Sep 2022 13:47:29 +0200 (CEST) Received: by mail-lf1-f46.google.com with SMTP id a3so19361248lfk.9 for ; Fri, 23 Sep 2022 04:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date; bh=wbTuaPb5hH66you+94hGBbcEW7Z1NjcWx6nauq95Yr8=; b=f2sdKAGqfEb360i7/uSh8+ZktzMCVBzuEOsNkHDZoITpLfvXcYcdR5RpWcM6Nj68Zi Hc+EuiitnPKlbnI4O6JCeMGzVtcbIRkTulDOm8LbFPixPXlwGHVKWgISkDEfxulOynBE YO/Db9ouPBnTSirrdq/GE1wEOg/NFyt+dtTAwPgNTx0P5cH5oqbyRkYPiXz3dlVO2ALq v48abJeLds8Z8zpAc+5xYNXWvXEEXSE1/Qp2fn1iRnOXBsajL6HAR+cPGo8ExO4CUhKF 6QrJJFZrwcHUPVnbZ2uaxNLNDuv1RWiMX2hEsIVJIDs1HWTM8bEkAdeLMngEMAN4HEPl XMGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date; bh=wbTuaPb5hH66you+94hGBbcEW7Z1NjcWx6nauq95Yr8=; b=c6UaPaCBUS8RcgZOtKfF4fZLmRdvpRwbR8tVUU/a99SwP7VX270IyzkR6bw+mk1p+4 yGJ0PPWUp+zyYE0VaihgKzpoXqul8C5RBCP/YC7Mzih6LidHL0oUx+IMBLf+4SnYLMLX IjCmK2cm/rGT/HSKK1qUXiqblxnbSoJ/W0NdUPMVjhqNwBaxVKQMnRhsm1ykwCcR/XB5 XzxzqfsLYMJUdJwKhIYynEP6cjw/TSY8pUAGeS6LA8vFVW2dkqZOURoveRABEowGQxUu UOI56ortDefDb7eiiVvx3XxIILoVNcc2HE0lkV32oqUjqsjkxSn3u4csJWBVVL4GtaOp uZJQ== X-Gm-Message-State: ACrzQf2Lki6R9rzDouGsfX989istaat7gq9TEZVXkmF0f21R6nxRSiWj VzglXJnAYKm43UfgE0ty8ZU= X-Google-Smtp-Source: AMsMyM4D1dfu5mLznakJ3AF6b5iQPR7vFMdHFitPo7yUXejvPPrveV01Rjz77UQk8IXevZMVQRHyTg== X-Received: by 2002:a05:6512:3c8d:b0:49a:d44b:41d with SMTP id h13-20020a0565123c8d00b0049ad44b041dmr3150801lfv.690.1663933648845; Fri, 23 Sep 2022 04:47:28 -0700 (PDT) Received: from sovereign (broadband-37-110-65-23.ip.moscow.rt.ru. [37.110.65.23]) by smtp.gmail.com with ESMTPSA id a30-20020a194f5e000000b0049d3614463dsm1419103lfk.77.2022.09.23.04.47.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 23 Sep 2022 04:47:28 -0700 (PDT) Date: Fri, 23 Sep 2022 14:47:27 +0300 From: Dmitry Kozlyuk To: "Umakiran Godavarthi (ugodavar)" Cc: "anatoly.burakov@intel.com" , "dev@dpdk.org" , "stephen@networkplumber.org" Subject: Re: DPDK 19.11.5 Legacy Memory Design Query Message-ID: <20220923144727.155be566@sovereign> In-Reply-To: References: <20220922120052.710c2cd1@sovereign> X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 2022-09-23 11:20 (UTC+0000), Umakiran Godavarthi (ugodavar):=20 > [Uma] : Yes we are unmapping the entire range hoping all are free inside= DPDK and DPDK heaps never use these pages. >=20 > Suppose we have 400 pages total free_hp, we want only 252 pages , so we r= educe nr_pages to 252. >=20 > So we assume 253 to 400 inside DPDK are free as we nr_pages are made by m= y application as 252. >=20 > ms_idx =3D rte_fbarray_find_next_n_free(arr, 0, 2); -> 253 comes > ms_check_idx =3D rte_fbarray_find_next_n_free(arr, 0, RTE_PTR_DIFF(RTE_PT= R_ADD(msl->base_va, msl->len), addr)/msl->page_sz); -> 253 comes (should be= same as above) > ms_next_idx =3D rte_fbarray_find_next_used(arr, ms_idx); -> This comes -= 1 as NO USED page is there (<0) >=20 > Hence we call unmap like -> munmap(addr, RTE_PTR_DIFF(RTE_PTR_ADD(msl->ba= se_va, msl->len), addr)); >=20 > Please let us know how to check in DPDK free heaps or FBARRAY that these = pages we are freeing are really safe ? (253 to 400 unwanted pages by our ap= plication, other than above 3 checks) >=20 > If it=E2=80=99s not safe to free, how to inform DPDK to free those pages = in FBARRAY and also clean up its heap list so that it never crashes !! There still DPDK malloc internal structures that you cannot adjust. I suggest going another way: Instead of letting DPDK allocate all hugepages and unmapping some, allow DPDK to allocate an absolute minimum (1 x 2MB page?) and add all the rest you need via rte_extmem_*() API. Why do you need legacy mode in the first place? Looks like you're painfully trying to achieve the same result that dynamic mode would give you automatically.