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 224A9A0544; Fri, 23 Sep 2022 14:12:32 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 001CB4003F; Fri, 23 Sep 2022 14:12:31 +0200 (CEST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by mails.dpdk.org (Postfix) with ESMTP id 244F14003C for ; Fri, 23 Sep 2022 14:12:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12675; q=dns/txt; s=iport; t=1663935150; x=1665144750; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=baN2T7h85SQLpeD+bdk0cmU6Y+xO+JQzbvLxxrveFd0=; b=EbyrwJfGrQ+KbdmON3FFIIqcsuj8W68o3UnwZ8JQTui6xYYRAtOIQYSM LSZw65vYSXcwJk1x7Bv1WDbCezlKcxZU5+UuILzPgE7thr8ADVt6+ktJY iETHyXI9JLQ86Sn2fpgxXxf35Vu8dCm1eAnDdKJHsTQ/YIyHC0QwmrlKy s=; IronPort-PHdr: =?us-ascii?q?A9a23=3A200j8BSplu6XDJI3P6/EgGkiF9pso7vLVj580?= =?us-ascii?q?XJvo75Nc6H2+ZPkMQSf4Ph2l1bGUM3d7O4MkOvZta3sGAliqZaMuXwPatpAA?= =?us-ascii?q?hkCj8hFkwkpGsXQD0r9IbbjZDA7G8IXUlhj8jm7PEFZFdy4aUfVpyi57CUZH?= =?us-ascii?q?VP0Mg8mTtk=3D?= IronPort-Data: =?us-ascii?q?A9a23=3A3cY3WK3NoYHcXswPCfbD5TFzkn2cJEfYwER7X?= =?us-ascii?q?KvMYLTBsI5bp2EAmGVLWjvTafyKMWDxKYxwPtu09UpQ6J6EzIc2TFRq3Hw8F?= =?us-ascii?q?HgiRegpqji6wuYcB84ZRyH6ZBoPA/42N5+RdajYcleG/k33auW48yElvU21b?= =?us-ascii?q?uOU5NDsa3gZqTBMEE/NuTo78wIIqtYAbeqRWmthivuqyyHrA2JJ7hYvWo4iB?= =?us-ascii?q?w1vnzs01Bj6kGtwUlXT/pmntneG/5UeJMp3ya1csxLFrodo8u6SH44vzZmj9?= =?us-ascii?q?W/fuhwqEN7gzvDwc1YBRfjZOg3mZnh+Avf5xEMd4H1plP9maZLwam8P49mNt?= =?us-ascii?q?81+z9lEq5WqYQwoJabL3u8aVnG0FgknZfMYpu+ZeyPi2SCU5wicG5f2+N11E?= =?us-ascii?q?EwuPYAe0uB6HX5J7/8ALC0IZB2ZweWsz9qTRuRyrsg7IMqtO5kQ0llpyzjFC?= =?us-ascii?q?vI3B5reWazJ4sFw3TEsi8QIFvHbD+IVbDtzdgWGYBpdPlYKC7oxme6pgj/0d?= =?us-ascii?q?Dgwlb4/jcLb+EDJxwB3lbPqKteQJpqBRN5emQCToWeuwogwOTlCXPT39NZP2?= =?us-ascii?q?ijEajfzoB7G?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A9Nel9a+1LMvQU/YJcEBuk+Fmdb1zdoMgy1?= =?us-ascii?q?knxilNoENuHPBwxvrAoB1E73PJYW4qKQ0dcdDpAtjlfZquz+8L3WBxB8buYO?= =?us-ascii?q?CCggqVxe5ZnPPfKlHbak/DH6tmpNpdmstFeZHN5DpB/L3HCWCDer5KqrTmgc?= =?us-ascii?q?OVbKXlvg1QpGpRGsZdBnJCe3+m+zpNNW977PQCZf+hz/sCgwDlVWUcb8y9CH?= =?us-ascii?q?VAdfPEvcf3mJXvZgNDLwI76SGV5AnYp4LSIly95FMzQjlPybAt/SzuiAri/J?= =?us-ascii?q?iutPm911v1y3LT1ZJLg9Hso+EzSvBky/JlawkEuDzYJ7iJaIfy/gzdZ9vfrW?= =?us-ascii?q?rCpeO84yvI+f4Dr085MFvF5icFkDOQrgrGo0WSuGNwx0GT5/AQgFkBepJ8bU?= =?us-ascii?q?UzSGqB16NohqAN7Itbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0WbW?= =?us-ascii?q?IyUs4mkWUkxjIdLL4QWCbhrIw3GuhnC8/RoP5QbFOBdnjc+m1i2salUHg/Fg?= =?us-ascii?q?qPBhFqgL3e7xFG2HRii0cIzs0WmXkNsJo7Vplf/uzBdqBljqtHQMMaZb90QO?= =?us-ascii?q?0BXcy0AGrQRg+kChPYHX33UKUcf37doZ/+57s4oOmsZZwT1ZM33I/MVVtJ3F?= =?us-ascii?q?RCDH4Gyff+qKGj3iq9NVlVBw6duf22z6IJyIHBeA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuBgB2bIJi/5tdJa1agQmBT4EhMSo?= =?us-ascii?q?oB3UCWDlDiBoDhTGFCYMCA4sUixGFE4EsgSUDVAsBAQENAQFCBAEBhQIChT4?= =?us-ascii?q?CJTQJDgECBAEBARIBAQUBAQECAQcEgQkThWgNhkIBAQEBAxIVGQEBNwEPAgE?= =?us-ascii?q?IEQMBAi8hER0IAgQOBQgaglyCDFcDMQGfdQGBPgKKH3iBATKBAYIIAQEGBAS?= =?us-ascii?q?FDQ0LgjgJgTyDFIMCgSWHJSccgUlEgRQBQ4JnPoIggiYeBoNngi6OBIddBzo?= =?us-ascii?q?DVIEFEoEhcQEIBgYHCgUyBgIMGBQEAhMSUx4CEwwKHA5UGQwPAxIDEQEHAgs?= =?us-ascii?q?SCBUsCAMCAwgDAgMjCwIDGAkHCgMdCAocEhAUAgQTHwsIAxofLQkCBA4DQwg?= =?us-ascii?q?LCgMRBAMTGAsWCBAEBgMJLw0oCwMUDwEGAwYCBQUBAyADFAMFJwcDIQcLJg0?= =?us-ascii?q?NBBwHHQMDBSYDAgIbBwICAwIGFwYCAnEKKA0IBAgEHB4lEwUCBzEFBC8CHgQ?= =?us-ascii?q?FBhEJAhYCBgQFAgQEFgICEggCCCcbBxY2GQEFXQYLCSMcHAEPCwYFBhYDJlI?= =?us-ascii?q?FBB8BlxwuNYEhgTglCJMXFI1ioBhrCoNMjWSMKYYZFYN1jD6YJJZmkQCQdIU?= =?us-ascii?q?KAgQCBAUCDgEBBoFhPIFZcBU7gmhRGQ+PRgEIgkOKXnU7AgYLAQEDCZEaAQE?= X-IronPort-AV: E=Sophos;i="5.91,230,1647302400"; d="scan'208,217";a="1066686235" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Sep 2022 12:12:28 +0000 Received: from mail.cisco.com (xfe-rcd-005.cisco.com [173.37.227.253]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 28NCCSwm005607 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2022 12:12:28 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9; Fri, 23 Sep 2022 07:12:28 -0500 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9 via Frontend Transport; Fri, 23 Sep 2022 07:12:27 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=disxj/QfV+vtgk1BZNrtKt2FiEzjpJiZ/D1p0T3Uax9WS+BSVq7kjVHOYcK5Cu+ppcgFgJrf8y4tPbEjcBW4HkKkW09fNtqsZRyXGFaByMOBl1iO/HH2GTNKoWPogS+Dh0gw3Z3JOuuKOWiQHPAD5eBZgKGjZqA27+X+cXXVZSrkL+aeEEnVrK5JXpQ8TCyALAcpUfcgl2eQYzrJyfrVA0p5UwdvtMDtRcAtHXRhBTSKdDhtNBe2xtJ4msXli1YKAICwvQ7D8/Ns9pbiW3uYuxwJxOAcxDePfV8ju2C+H7/bEjDl6qL5T10s6HHxyx/NOcFK2VQb+isdH01BUROnfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=l0WHijvTcUeI5lW31F/8HpMyYV0qpnLCI7AOMGpTuS8=; b=FKUojLKYaH/CspSyOIqfcBoALe6X7/lXVNdTnUNr6Ytrbx8D8gm2lJv09tK2RM/V8/4H1zVrjHEvIDVBgcH+mwLrOfF9wEIlGzNb427lQCpQLO9N514nIMfWzT3GuEXc3D9DVV3sVsWjqxYC6u2AUqxau7yE9+TFRGcesAKBi+SIfalZxaVoIxx87XqHZrWo2cfsMTX34ysTgzj3bBByuRsSqLbBZxt3SbNnNgoGcV8k5E4f9MK7Hg3UVQI0sI8m+NrV9O/W1Ea0T1KnYKJE3Em1I9dlZS9JcTcS244E0uQn/zN1Q7i2bOyL+7EuCb11E3HuZ4EjkAeWNJev+hU/sw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l0WHijvTcUeI5lW31F/8HpMyYV0qpnLCI7AOMGpTuS8=; b=DXOTc4ufj+4dYyQo8tO3JleoWdocCspHpeYHeY5WZJWSBQ5/Wz22WPjwcyQm2wC/Ys/JIEOZ719mVkZZ8pl+HNwxpPWc1ZQV8ZnMLtHBw/IYHTTRNfls0OI+6ZBSvU4mpsb3dsjuaPnpLZ9uMZGavWKNvzbBuKqCEkoVbBsR3nU= Received: from SJ0PR11MB4846.namprd11.prod.outlook.com (2603:10b6:a03:2d8::24) by SJ0PR11MB4862.namprd11.prod.outlook.com (2603:10b6:a03:2de::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.20; Fri, 23 Sep 2022 12:12:25 +0000 Received: from SJ0PR11MB4846.namprd11.prod.outlook.com ([fe80::bf52:6035:504a:808c]) by SJ0PR11MB4846.namprd11.prod.outlook.com ([fe80::bf52:6035:504a:808c%7]) with mapi id 15.20.5654.020; Fri, 23 Sep 2022 12:12:25 +0000 From: "Umakiran Godavarthi (ugodavar)" To: Dmitry Kozlyuk CC: "anatoly.burakov@intel.com" , "dev@dpdk.org" , "stephen@networkplumber.org" Subject: Re: DPDK 19.11.5 Legacy Memory Design Query Thread-Topic: DPDK 19.11.5 Legacy Memory Design Query Thread-Index: AQHYyAmT17eWxN4VFkO+VD/TnQXrtK3pfBK4gAGoheSAAA73AIABtqxUgAAKNICAAAVZ9g== Date: Fri, 23 Sep 2022 12:12:25 +0000 Message-ID: References: <20220922120052.710c2cd1@sovereign> <20220923144727.155be566@sovereign> In-Reply-To: <20220923144727.155be566@sovereign> Accept-Language: en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ0PR11MB4846:EE_|SJ0PR11MB4862:EE_ x-ms-office365-filtering-correlation-id: 035856ea-8efe-4a6a-ec43-08da9d5ce0a3 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TQnr/yeH+wVrEtOX3qygnUFnQGtT445TOU4rRv7lvvVWgxFPPTUF8qKdezgfbfIUweGXL46wSy+KLW5Un+xLY18zOg34+A6SWRevYPiu5u6FQfVtroehbKTTJ2m9u/QlFhUMGpZ6nZofQg6Y2p8OgwqQxjjp9nLiwmFnk3sNrLRhx9xcZ+xiKl+YDYMB6YdmUEhvzKkL3TKVyux6vfvp10AqjNECVuZfm5DMtJx2jHxc9E2EDOGIy5MAD+xlO5kfXkuzjJGK7ITl2iTxeFxjNQRQYN6wgDaPsTbwVjy0uQpvRenjzX6tTQ0xyh2s5xEz0rE8hVE5ZYy67JORgZpBlrPEHzJ/Dv78cDk/kg/P+QcIaJ8D8O5VM++JH3lKbykXY7pxNFfGRy/0I2946TY9C8dYuBLNyBsvMTMCopdGPaQkhG+m3aiRlpwz4I3ZXS4gSBvWZT8oy367v1ay6SpiDqTCcPiLEGhAY0WbjvciwjxcaOQBhog0wysMAsJSkZx+696z7FMOhMXXPmaOz8OYWgb26MdKB0J3WGfETZ0Gjgsv5yFOiSWgvvYGox4i/6Gpl4LHiuWwCiW9cNJoWClOIP7DcDEb6/GSVD3A9Wpo0wm6qtP9puvP4sHJcPAaMTiSasTRk7XHOgxBr6Ra/pC/sZkp6I6nAzm+1K1zqc0fmbzVdHAUhZTGIi7jiUa74RoijC+3SPrR5iGjoHe3+aj3gnPeB4sAWqQ/I5cKUzm7Ts9vT/0hWPFeUL6dYDR+IvEaX4QxUPx5DcwmMdJcsgBxxA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR11MB4846.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(4636009)(346002)(376002)(136003)(39860400002)(396003)(366004)(451199015)(71200400001)(316002)(52536014)(478600001)(5660300002)(86362001)(8676002)(33656002)(4326008)(76116006)(66556008)(66476007)(66446008)(41300700001)(64756008)(8936002)(66946007)(91956017)(6916009)(54906003)(38070700005)(38100700002)(122000001)(55016003)(53546011)(7696005)(6506007)(186003)(83380400001)(9686003)(26005)(55236004)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?ebtxLeOzQI3T87yG7J7JC+lTL3anawbY3bE5VRB4uUPIqLgiuTtu/FB0?= =?Windows-1252?Q?2ZjSgQxT04cXAZy9+D0ECnJ1H96vNWav2P91o4QVW81mK2cZJNWczfaV?= =?Windows-1252?Q?70o7Hm8lJMj/ayMnTUM/NDuKZvGJaEVCQJDQg8HvRBLQO4OQiGFeINde?= =?Windows-1252?Q?zefFK7vN3jV2K1RCVF1d3CKfEaG1b8Q0fxcGZoFLiIOf/Atb837S0RM5?= =?Windows-1252?Q?IpEmCG0wlyOMGuH6oroYxVyc9sDfiKFzWZzY3caviMRLp4etJPhVqBu2?= =?Windows-1252?Q?S4qfwU85U29L/SIfJuoM/u8gggSEFTkv3XTvGstdup7wYPT7bpL2jQji?= =?Windows-1252?Q?N7J90ioFbfcmjH+mTiB9kAp1tufs7qeMd/0XINo6f4Ss6WmUUDREWmx4?= =?Windows-1252?Q?zag7uAhV4zR6g4OXq440j9c0cstJmcEKrEBEU/V6oVhcmllcWYTKPI9j?= =?Windows-1252?Q?tZtds6axBq4NsAZOngiFrSPFXyXbW2bu+5g90vekSXnHa4xzivnyhSqo?= =?Windows-1252?Q?U1WhzBszUwwywr4olAjgB87njmsx3wcbjJwVm4NQqGfU6M5qYLHAYRHA?= =?Windows-1252?Q?SpTzmGY15YQIcTs3WY+QEBXOyBhXo29BSiftWMNA6g91Ckr3Uh33gF/X?= =?Windows-1252?Q?Xi08neHiTaylyyPKnUVR6RZmh10VWXJ8SkWOJScl4C5Kj0YfNDinktyA?= =?Windows-1252?Q?tDpUO/Qy1HTDgAVZWfn7pjhvyGNChnc8hj0o8hxCu8rla6lkGBrHHSng?= =?Windows-1252?Q?9BAYHqf+0K1XiA/eDHFNkl66fAIjFO+3Uvt1/hx6JcsLJiQ0o9SoCwSr?= =?Windows-1252?Q?pVLuX0C4/NI53jeiHJOw/wq7Fh5dKTQH39lvVoP/Yt9a7DHfPRt0Aet8?= =?Windows-1252?Q?8DBsfb618TxPd5qxQEhkxE6mX5lCRf5tOv2qhGNoxZsG0kzESF6E55Xw?= =?Windows-1252?Q?vfjR8CFNpUJ6D7CXJIiU3PRrXtrw4fSIBIJznzvHostzLRae5QCQv9iw?= =?Windows-1252?Q?Uf2GPIGykyluBjZC0ioAd719HOBO7slLFVRbKlfLpu55E184LdMNIqIP?= =?Windows-1252?Q?PzM3WTY0hHH8qojerxjfBsLA/lYZng/EWJM5AZDJ0/jWEhuoLJ3SlNpF?= =?Windows-1252?Q?zkgJcSKzzCvxudl04lvAdL+IfDlNylNNhzV7FWEO+NkmwlqNrWdKDW7b?= =?Windows-1252?Q?GN+pf2tjSla2mhhnAavvgBYzHfS+aWGsAkmH6FG25oGy7RLbwefuYkNZ?= =?Windows-1252?Q?sAuyTXwc5wGMkIjqM4LyVBgI59HDbkwzIMZyslC36KGqMx6PbN/gYtyK?= =?Windows-1252?Q?bKnx0OcjnH6vWI5FOa6VyfbeDoaJint6vIMmjkN34tgEeUsdn0lJWYVv?= =?Windows-1252?Q?Uk3tBeLcDDNRIXZ/gpGVu2G56WX/4zeAO+xPhueaP+qrmIhKp3S+1URi?= =?Windows-1252?Q?yORGXlrfV+cuTfRZVE8xClXdJdPexN+niC6rXvqsZWEaAdBcIw5MGu+L?= =?Windows-1252?Q?ZvY0M39QpGP6hfHIZ/95TgZaJoBnQDdc5jdZioC4KUZzrNc8JjqHn0G9?= =?Windows-1252?Q?NGiLUnGB3bG69MnGR7I4lox+KI8mj6jF0CkxnBh/6BqibCpyInZhGgD0?= =?Windows-1252?Q?Nmv41C9ybN6/l8zd3opJH6TleHDaIpK2/NRjaKU9PMbkn+3gYjMQ/Ny7?= =?Windows-1252?Q?oJWsIZaFPuB+IFskx2Z7AIe+yN5LXKtU4rpHxKkjm0xIf7BqEs27/w?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_SJ0PR11MB484605E55A5604175621DA6ADD519SJ0PR11MB4846namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB4846.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 035856ea-8efe-4a6a-ec43-08da9d5ce0a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2022 12:12:25.6487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7WV3wIAdf1sb/cvvn71uACoAGXoL2gSINoS3zH3u6Rku27nVcNV3oA17k4Z603r3EZldVjWLPhhPYfkiAUA8HQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4862 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.227.253, xfe-rcd-005.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com 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 --_000_SJ0PR11MB484605E55A5604175621DA6ADD519SJ0PR11MB4846namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Dmitry for quick turn around Yes below are my answers 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. [Uma] : Yes I agree if free_hp =3D 400, nr_hp =3D 252, we are expecting DP= DK takes only 252 and keep the remaining pages free in its heap. As you have mentioned just boot DPDK with 1 page, and add pa= ges we want later, is this the steps 1. NR_HP =3D1 , FREE_HP =3D 1 2. EAL INIT (DPDK boots up with 1 2 MB page) 3. What is the API for adding later on pages ? (rte_extmem_*, can you pl= ease give the full API details and how to call it with arguments ) We can do 1,2,3 there is a problem once we reduce pages to 1 , kernel will = free the huge pages totally So is there a way not to touch NR_HP, FREE_HP, and just pass arguments to b= oot DPDK with just 1 page ? Please let us know and later add pages we need = to DPDK !! 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. [Uma] : Yes , we can=92t avoid legacy memory design as secondary process ma= pped page by page to primary process , and physical addr space is same for = both processes. We have to stick to legacy memory design only for now !! Thanks Umakiran From: Dmitry Kozlyuk Date: Friday, 23 September 2022 at 5:17 PM 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 2022-09-23 11:20 (UTC+0000), Umakiran Godavarthi (ugodavar): > [Uma] : Yes we are unmapping the entire range hoping all are free inside= DPDK and DPDK heaps never use these pages. > > Suppose we have 400 pages total free_hp, we want only 252 pages , so we r= educe nr_pages to 252. > > So we assume 253 to 400 inside DPDK are free as we nr_pages are made by m= y application as 252. > > 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) > > Hence we call unmap like -> munmap(addr, RTE_PTR_DIFF(RTE_PTR_ADD(msl->ba= se_va, msl->len), addr)); > > 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) > > If it=92s not safe to free, how to inform DPDK to free those pages in FBA= RRAY 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. --_000_SJ0PR11MB484605E55A5604175621DA6ADD519SJ0PR11MB4846namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thanks Dm= itry for quick turn around

&nbs= p;

Yes below= are my answers

&nbs= p;


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.

[Uma] :  Yes I agree if free_hp =3D 400, nr_hp = =3D 252, we are expecting DPDK takes only 252 and keep the remaining pages = free in its heap.

        &nbs= p;      As you have mentioned just boot DPDK = with 1 page, and add pages we want later, is this the steps

  1. NR_HP =3D1 , FREE_HP =3D 1
  2. EAL INIT (DPDK = boots up with 1 2 MB page)
  3. What is the API for addi= ng later on pages ? (rte_extmem_*, can you please give the full API details= and how to call it with arguments )

 

We can do 1,2,3 there is a problem once we reduce pa= ges to 1 , kernel will free the huge pages totally

 

So is there a way not to touch NR_HP, FREE_HP, and j= ust pass arguments to boot DPDK with just 1 page ? Please let us know and l= ater add pages we need to DPDK !!


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.

 

[Uma] : Yes , we can=92t avoid legacy memory design = as secondary process mapped page by page to primary process , and physical = addr space is same for both processes.  We have to stick to legacy mem= ory design only for now !!

 

Thanks

Umakiran<= o:p>

&nbs= p;

From: Dmitry Kozlyuk <= dmitry.kozliuk@gmail.com>
Date: Friday, 23 September 2022 at 5:17 PM
To: Umakiran Godavarthi (ugodavar) <ugodavar@cisco.com>
Cc: anatoly.burakov@intel.com <anatoly.burakov@intel.com>, dev= @dpdk.org <dev@dpdk.org>, stephen@networkplumber.org <stephen@netw= orkplumber.org>
Subject: Re: DPDK 19.11.5 Legacy Memory Design Query

2022-09-23 11:20 (UTC+0000), Umakiran Godavarthi (ug= odavar):
> [Uma] :  Yes we are unmapping the entire range hoping all are fre= e inside DPDK and DPDK heaps never use these pages.
>
> Suppose we have 400 pages total free_hp, we want only 252 pages , so w= e reduce nr_pages to 252.
>
> So we assume 253 to 400 inside DPDK are free as we nr_pages are made b= y my application as 252.
>
> 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= _PTR_ADD(msl->base_va, msl->len), addr)/msl->page_sz); -> 253 c= omes (should be same as above)
> ms_next_idx =3D  rte_fbarray_find_next_used(arr, ms_idx); -> T= his comes -1 as NO USED page is there (<0)
>
> Hence we call unmap like -> munmap(addr, RTE_PTR_DIFF(RTE_PTR_ADD(m= sl->base_va, msl->len), addr));
>
> Please let us know how to check in DPDK free heaps or FBARRAY that the= se pages we are freeing are really safe ? (253 to 400 unwanted pages by our= application, other than above 3 checks)
>
> If it=92s 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.

--_000_SJ0PR11MB484605E55A5604175621DA6ADD519SJ0PR11MB4846namp_--