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 3FEBAA0544; Fri, 23 Sep 2022 13:20:44 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 052E240156; Fri, 23 Sep 2022 13:20:44 +0200 (CEST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by mails.dpdk.org (Postfix) with ESMTP id 4B0434003C for ; Fri, 23 Sep 2022 13:20:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17464; q=dns/txt; s=iport; t=1663932042; x=1665141642; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=foFRTUB8JSmCyffV0boUKCytS711AQlrZJeYSDbZAz0=; b=Tj++tfy9JnnrlJB19yhlWu6eBWbQ1q0toOelliJqpSj1gXI6tVZgKdDY nD0TsuKyHR6zmnWMlJmiHLeWAAUcsBayIzZBIpiHnxx4YcgwKilI+pbYP ltI7oqpuU6mvYcVItxKlhltfzKJoJ8JIyqOKq4fENOaCtp5XUPKrQJ/va o=; X-IPAS-Result: =?us-ascii?q?A0CdAgCplS1jmIkNJK1agQmBT4EhMVJ/Alk6RYgaA4Uvi?= =?us-ascii?q?BYDiyqLIYUagSyBJQNUCwEBAQ0BAUIEAQGFBQKEbAIlNQgOAQIEAQEBAQMCA?= =?us-ascii?q?wEBAQEBAQMBAQUBAQECAQcEFAEBAQEBAQEBHRkFDhAnhWgNhkIBAQEBAgESF?= =?us-ascii?q?RkBATcBBAsCAQgRAwECLyERHQgCBA4FCBqCWwGCFlcDDSMDAaAMAYE/Aoofe?= =?us-ascii?q?IEBM4EBgggBAQYEBIURDQuCOAmBPYMyg1GBRodgJxyBSUSBFUOCZz6CIIImH?= =?us-ascii?q?oNugi6EBpUPBzcDRB1BAwtCNBgDFAMFJAcDGQ8jDQ0EFgcMAwMFJQMCAhsHA?= =?us-ascii?q?gIDAgYTBQICTTYIBAgEKyMPBQIHLwUELwIeBAUGEQgCFgIGBAQEBBUCEAgCC?= =?us-ascii?q?CYXBxMzGQEFWRAJIRwOGg0FBhMDIG8FRA8oMWsrHRsKgQwqKBUDBAQDAgYTA?= =?us-ascii?q?wMiAhAqMRQEKRMSLQcrcwkCAyJnBQMDBCgsAwkgBBwHKCY8B1g6AQQDAxAiP?= =?us-ascii?q?QYDCQMCJFuBLigFAw0ZJggFIxcdBAg8AgUGVxMCChIDmXRzgSEvRnA1oQ2gS?= =?us-ascii?q?24Kg1iOB4wshiEWg3aMUJg+lwqRI5YdAgQCBAUCDgEBBoFiATiBW3AVO4JnU?= =?us-ascii?q?RkPjiwNCYNQil51OwIGCwEBAwmKYQEB?= IronPort-PHdr: A9a23:lBNcsBQvcCKlU6li77NFyLscL9pso7vLVj580XJvo75Nc6H2+ZPkM QSf4Ph2l1bGUM3d7O4MkOvZta3sGAliqZaMuXwPatpAAhkCj8hFkwkpGsXQD0r9IbbjZDA7G 8IXUlhj8jm7PEFZFdy4aUfVpyi57CUZHVP0Mg8mTtk= IronPort-Data: A9a23:kbLAUKtuzQRwObPTSQK1vaHKG+fnVJJeMUV32f8akzHdYApBsoF/q tZmKWvTPfnbNzahKIt1O4S09UpS7ZSEyd5kSldr/HxkRHwbgMeUXt7xwmUckM+xwmwvaGo9s q3yv/GZdJhcokf0/0vrav67xZVF/fngqoDUUIYoAQgsA14/IMsdoUg7wbRh09Qz2YLR7z6l4 LseneWOYDdJ5BYsWo4kw/rrRMRH5amaVJsw5zTSVNgT1LPsvyB94KE3ecldG0DFrrx8RYZWc QpsIIaRpQs19z91Yj+sfy2SnkciGtY+NiDW4pZatjTLbhVq/kQPPqgH2PU0dUB5pznUvNJL2 otKj6OzZEQxY4bwsbFIO/VYO3kW0axu8bvDJz20ttaeihGAeHr3yPIoB0YzVWEa0r8oWicVq 7pBc3ZUNU/ra+GemNpXTsFxicMvJdfiJqsUu2prynfSCvNOrZXrEvyRu4YHgWdq7ixINarMQ vMdNRRsUAn7Uyx/ZFdHNcwSo+j90xETdBUB+A7K+sLb+VP71xB8yLjgNvLTd8CVQt9WhkKFo 2jL5SL+GB5yHNCS1xKJ6n6vwOjVkkvTUYQbCLq857hgnUeaxWsNIBwQSVa/5/K+jyaWV9deN 1YFvCkpv6wz6U+DQdz0Xhn+q3mB1iPwQPJZF+k8rQqK0KeRv0CSB3MPSXhKb9lOWNIKqSICy lins9+0Jj5VouOSc02e2/SM8BiOEH1ARYMdXhMsQQwA6tjlhYg8iBPTU9pueJJZaPWoRFkcJ BjX8UADa6UvYd0jjP7ipA+Z6964jt2YEFBqt1y/sneNtFsRWWKzW2C/BbE3B95pKIKUSDFtV 1BbxpDHt4ji4Xxx/RFhrc0EGLWvov2CKjCZ3RhkHoIq8HKm/HvLkWFsDNNWeRcB3iUsIGCBj KrvVeV5v8U70JyCNvUfXm5JI552pZUM7Py8PhwuUvJAY4JqaCiM9zx0aEib0gjFyRZyyvFgY MvALJ71Uh727JiLKhLrGI/xNpd2lkgDKZ/7GfgXMjz+i+PFPS7JIVv7GArRM4jVE59oUC2Mo 4oAaKNmOj1UUfb1ZWHM4JUPIFURRUXX9riow/G7gtWre1I8cEl4Uqe56ep4J+RNwf8P/s+Wp S7VZ6Ot4Ael7ZExAV/UOikLhXKGdcsXkE/XygR2YgvygSh8O973hErdHrNuFYQaGCVY5aYcZ 5E4lw+oW5yjlhyvF+whUKTA IronPort-HdrOrdr: A9a23:IFUOQKhWwrpZgs1YKgwwb0OGLXBQX2R13DAbv31ZSRFFG/FwyP rBoB1L73DJYWgqNE3IwerwRJVpQRvnhPpICPoqTMiftWjdySaVxeRZjLcKrAeQYxEWmtQtt5 uINpIOdeEYbmIKwfoSgjPIaOrIqePvmMvD6IeurEuFDzsaEZ2IhD0JbTpzZ3cGPTWucqBJcq Z0iPA3wgaISDAyVICWF3MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWnW4j4uFxd0hZsy+2 nMlAL0oo+5teug9xPa32jPq7xLhdrazMdZDsDksLlaFtyssHfoWG1SYczAgNkHmpDs1L/sqq iIn/4UBbUy15oWRBDwnfKi4Xim7N9k0Q6d9bbRuwqTnSW+fkN9NyKE7rgpKicwLCEbzYhBOe twrhKknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTOIlGfdsRKEkjTVo+a07bWvHwZFiFP MrANDX5f5Qf1/fZ3fFvnN3yNjpWngoBB+JTkULp8TQilFt7TpE5lpdwNZakmYL9Zo7RZUB7+ PYMr5wnLULSsMNd6pyCOoIXMPyAG3QRhDHNn6UPD3cZeo6EmOIr4Sy7KQ+5emsdpBNxJwumI 7ZWFcdrmI2c1KGM7z44HSKyGG4fIyQZ0WZ9igF3ekLhlTVfsuYDRG+ X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.93,339,1654560000"; d="scan'208,217";a="913617582" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Sep 2022 11:20:40 +0000 Received: from mail.cisco.com (xfe-aln-004.cisco.com [173.37.135.124]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 28NBKefa030289 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2022 11:20:40 GMT Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xfe-aln-004.cisco.com (173.37.135.124) 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 06:20:40 -0500 Received: from NAM04-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-003.cisco.com (64.101.210.233) 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:20:40 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=naon07Vru1EWzn1Vj1xFK09PPCa831cf6pqRA1fxYE5yv4A1c2RInN2mMKSjPIeZPGeh5ZaWhoG3QoLD1/qC7oFdvliAIUJQIKFlyiSBSNtN3A8n1NNf9HTkSI1BXo25fAsrL41+aPNxDqdALJ85ugyDogCCuCG5v+wokG+kBBuLHxAMoOmGwbpdMJDpaZ73OszHTZndajW0hiz6pPHNgXdUNq4O1IfYA9PMS/gm5iQaTIWRHMswm0AtcPcYxE3XGA3fCKG14QAU7f0NOwN48Kte2Q1/7x7GWBT/N9Jae4jvdUVk+ZM61CTssj5HLRiR7pr6NClc6VWMspTymgDJpg== 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=M74gU8wfQi6dPu//QyxzvCcIfq//OYR2w9LNfVjCgNY=; b=W7QEnnxA0SlqJk97nnywdYz8xJO7P8Vz1kcSWCtVPmnANhDAVCyRFSawAAYGR0hUjFeFw4pPQxMSYyr8LtLVm0plandWE4Q5mzSrp8KsJDwhXB7NYQ1V4wTjBdM/9uQB4kJ5PDZXPYt9vXdGmc2BlzpBrUIcGSP2KjVtkUvyZ4mhbWRQKO8kL4YA0gCPJ89LfRMfGoBaxvpcTMqgSOtOim3+9wtk5UkInfXFIdid8GGVAIAbTqs3quNDvOJGDj/h5dwbJAXjG6LlSd61q1UB2ibXmApoJp6ARP7Gz41Xm54bZn/gNYCEQqttXNiEXBm0HOazrZc7krIgmlppsp3NaA== 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=M74gU8wfQi6dPu//QyxzvCcIfq//OYR2w9LNfVjCgNY=; b=x5g8/r41PG2mVR/fWqmTwJtWjoLMxQVSIzUXgVNq0muGDZQLOoiZOYwqdIUhCnek2KCmJGOlsBv5YngtUCwiStvmWGrC7Owlq5uHmSNfHYRwuIVL5dgH9VoBZ8Qt8OHtdcCEhd4EavVPv2K4BQPYCtDp+sXT3A+9YrX2N/l/Mvo= Received: from SJ0PR11MB4846.namprd11.prod.outlook.com (2603:10b6:a03:2d8::24) by IA1PR11MB7388.namprd11.prod.outlook.com (2603:10b6:208:420::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.14; Fri, 23 Sep 2022 11:20:38 +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 11:20:38 +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/TnQXrtK3pfBK4gAGoheSAAA73AIABtqxU Date: Fri, 23 Sep 2022 11:20:38 +0000 Message-ID: References: <20220922120052.710c2cd1@sovereign> In-Reply-To: <20220922120052.710c2cd1@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_|IA1PR11MB7388:EE_ x-ms-office365-filtering-correlation-id: 76bf6ac2-b925-4db9-e157-08da9d55a45f x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: S1zxfdbXymj/UAkyySS2+L0+N9YszJ8zeAtGOZF5KuqgP5icfuJ2kPLHkgl0Xe7znibRMNOyqoWPCUBGgbeeJq69ElJf+4YjGnGaU/Dhm4PBNmVhtoxblffrcZkayBPsrRBHGzZcPeKQqJdsOTdp2AZayfMXJXTDMcP2DHf1PeaR2oEewP1ATT5Q7Bk0SlmYYwG5QM8v9N16hlkFvCClRKtEVp0vcLoi6DALVTRV9XrtNebyqpujkZ1tQPEet4J0s/njdiX5AFSq5b5YGLsA8iQW5PlpEroNXMefp+++vO6pF/9IMYPkd05Epn0ty952nj7yoBSA/MAMXQ8ncghIwj8Y/tw5JqWVk553vnErq3IWsgGQTPMOrdz/VGpsRjO+l5pWDcgDrHrky1F9DAcwJI/iI/0hqURMt+c+tO7PXDfXY82e9tc+vA2OxA3ixkRJjy/7L95pXQ1RxrB61dlEGF9ju0uiLgS/5LSKUI3h/4Vh4DWDB2w8yJ5O5tqRbQTUy3KHm36JkEh0pNQygObq0eFMWC0UaN19RqMvLLaP3SZKPpCafv3DVJjoPxhdKMxUQUj9jBxlhHksuK9D7HYAQaZz2g/ySnWRzndq2LkKsq70ZDTSf1wRlRaCMb/A8qPXtKw5K90E8FmUBB4EUhiuOCu2MS1zVUeaO4JxRfOQtyUpylrwukX+v6I1cYo/vorDjLdjB2V4i6UCvfvpIo1I1JlWIqyalDpXehOPFMusP233lCjk59mhjB+31MInYX4ojxPj3wZILk36zekuxFAT7wHmCiVAy9rxywVWLHyeKSA= 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)(396003)(136003)(366004)(346002)(376002)(39860400002)(451199015)(478600001)(4326008)(53546011)(55236004)(71200400001)(26005)(55016003)(5660300002)(8936002)(6506007)(9686003)(7696005)(6916009)(54906003)(41300700001)(186003)(52536014)(38070700005)(76116006)(83380400001)(66946007)(33656002)(2906002)(64756008)(91956017)(66476007)(66556008)(66446008)(38100700002)(316002)(122000001)(8676002)(86362001)(309714004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?2sjHMLpb7wcl8bg1b+GVG8TMSzCxbX7uiUVBss1Vbyp8Wrn7gTieQ2j6?= =?Windows-1252?Q?yi03mcG+i+HEAqW1/YHHQq7duqB9qwmndC8pxgEOtoo2v6vZQkGy55rS?= =?Windows-1252?Q?j3xT/KMczaGCzqcI7+L/QwA4jRlERGGLQS2pVUKOC+s3W9sjCBmAUCdh?= =?Windows-1252?Q?XkrUMmPOKVI2b6DsYdCqdpV+UojsZz8oNk8dubnPIuqdlxtJlWtrX6+r?= =?Windows-1252?Q?TTuGDN/4IWjdDQWJ9eNsvQTDTFP02LFyh6KF3N7v1PFfd4f4RoOdzKCN?= =?Windows-1252?Q?yvgpcYthHf0WGgpGgjkOQszJ1wtT56vqiiLz5joQrPI72rfqiYYfaNse?= =?Windows-1252?Q?I5XXC9BMcJCDr+/OZGMYaaAwo/U+JeQthab3u8xEYSbXC+7K/RnxBneM?= =?Windows-1252?Q?F4ERZ6wLn5n9u+8Tta9xtBdq/BPxJQGXvEuNajncjOnVkkknQznoeGgE?= =?Windows-1252?Q?LcwnazfK6j7zGzjzhRadDjeZp8BMct3+trD2oRtoENAemCFQYr0cduMl?= =?Windows-1252?Q?QK0nYdwziD5kZCUfucd7CDSnXwV2DQ6ne1JymLctQz9ebRpRyxjvBwdc?= =?Windows-1252?Q?jV6OJs91ab3kwvUyuFdLFVXeltljQKvFw5kk49GhY/9aXzRju874WJJ2?= =?Windows-1252?Q?5zlIEZqe8YDpXEQCotRON7D6yVF6SCMf4WwlWpIJuOdHJv/84I3ZnZYj?= =?Windows-1252?Q?4BAjubtR82f9ez478Qs1kxaUYaJVQpC1FslW9T6/e0obCcuNt0is5gCX?= =?Windows-1252?Q?ycF7l40g6iIGQuRzNc7ekDJKqezWdQd5Fq6kgeRj4gR/6B/jPuzumNqf?= =?Windows-1252?Q?j/KY+8RE+/tbb9FefiFGnh0vlQmfBx4idUGiYQgXGwe8ZCL6H2euA/hY?= =?Windows-1252?Q?0U2ohRB4Sxij4wih8qmNbi24AyVOhGgkhGwZy6kTltlQgztFrH+j0d1Z?= =?Windows-1252?Q?L2aM307GKYA4AL3yT6JyHmurG4OchjNhD0V/BjVuMKvLaYsAnNVaAqNu?= =?Windows-1252?Q?pfeVB9rMT/hghN7H3tj9V96XCbss4oTRVjlkYLD9komQf6aZE+8deL2J?= =?Windows-1252?Q?q+YUywCU/1qvxSgABogfafuBniZprAP1BypEecJqet00+SgN7wbIst/z?= =?Windows-1252?Q?e9fw5uxLzk0Y3MdxrJ2VOVig6LH4w8cJKK/OkpA7W0KF5bjRFPytBFgg?= =?Windows-1252?Q?sdlB0ADcjoZx8/OO6XIvovAY+rYH8PtzgJVX/ANNdIW78uTKVj+dIf59?= =?Windows-1252?Q?iNw7AA8/NajSCiJGTbdonnzsP3oNs0hHKVtYZS/vW7HarlXPmfwP4Gs6?= =?Windows-1252?Q?jZdFBl7CibnESmfWga/fFrs7HCBn3mrxAymWJ9VmtjV60DLWatVLeB5b?= =?Windows-1252?Q?Y7CkPGSuP05l3cRayX+AMIcmT9c6lqg0T+EinYRyVZd+FglU0mW2giOZ?= =?Windows-1252?Q?YTk/97MAnkAttE4Ms+M/7zYPEQ5WDMSZz+K6Ixuom6xx4TIh/AKFodEt?= =?Windows-1252?Q?Wa1aUAleGHurB/vE/j5hxcNe1R0iQbqFm6NFE+foD0uVjr0La03EAeYb?= =?Windows-1252?Q?EVD8vGUsGMTKpI/ey9rUyyZ+r7x1TScWTktFewJVcUA/g+0Vmw/bNA9s?= =?Windows-1252?Q?8w7Ohfw40FosQYn2QRNsbDpCcHvLe6o4hmQF3AcTFrz7Qle2fis02BMd?= =?Windows-1252?Q?Wu53bkGmPCm+4Ns8WIml6a3Q4VxeHF2ECSuVzJdbmpW0QFITxEV5mw?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_SJ0PR11MB4846972B8C726C51A8E39797DD519SJ0PR11MB4846namp_" 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: 76bf6ac2-b925-4db9-e157-08da9d55a45f X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2022 11:20:38.1249 (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: ShNpEjuTXYCwNSC/R7HbMylRjWEkthtzgDMMxGn4PgqtUeuehItUvgXRtTDZ2JdPRasFLuggMUcWIpXX5NY+LQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR11MB7388 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.135.124, xfe-aln-004.cisco.com X-Outbound-Node: alln-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_SJ0PR11MB4846972B8C726C51A8E39797DD519SJ0PR11MB4846namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dmitry My answer for your reply You unmap memory, but you do not maintain DPDK memory management structures= , that is, DPDK does not know that this page is no longer usable. Probably this is the reason for the crash. You could print regions you're unmapping and the segfault address to confir= m. [Uma] : Yes we are unmapping the entire range hoping all are free inside D= PDK and DPDK heaps never use these pages. Suppose we have 400 pages total free_hp, we want only 252 pages , so we red= uce nr_pages to 252. So we assume 253 to 400 inside DPDK are free as we nr_pages are made by 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 comes (should be s= ame 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->base= _va, msl->len), addr)); Please let us know how to check in DPDK free heaps or FBARRAY that these pa= ges we are freeing are really safe ? (253 to 400 unwanted pages by our appl= ication, other than above 3 checks) If it=92s not safe to free, how to inform DPDK to free those pages in FBARR= AY and also clean up its heap list so that it never crashes !! We are suspecting this code below hits NULL crash or invalid address refer= ence for us static struct malloc_elem * find_suitable_element(struct malloc_heap *heap, size_t size, unsigned int flags, size_t align, size_t bound, bool contig= ) { size_t idx; struct malloc_elem *elem, *alt_elem =3D NULL; for (idx =3D malloc_elem_free_list_index(size); idx < RTE_HEAP_NUM_FREELISTS; idx++) { for (elem =3D LIST_FIRST(&heap->free_head[idx]); -> We ar= e suspecting elem is invalid address and hence crashed !!!! !!elem; elem =3D LIST_NEXT(elem, free_list)= ) { if (malloc_elem_can_hold(elem, size, align, bound, contig)) { Thanks Umakiran From: Dmitry Kozlyuk Date: Thursday, 22 September 2022 at 2:31 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 Hi Umakiran, > From: Umakiran Godavarthi (ugodavar) > Date: Wednesday, 14 September 2022 at 1:00 PM [...] > 1. Then we go to DPDK Memory segment list walkthrough and for each FBA= RRAY , we find the used pages by DPDK and unmap the remaining pages by belo= w code (Idea is to free the huge pages taken by DPDK process virtual memory= ) -> Free_HP will be 0 then, as X pages are used by DPDK and all unnecessar= y pages are freed in this step) > Sample Code of 4 : > > rte_memseg_list_walk_thread_unsafe(dpdk_find_and_free_unuse= d, NULL); ->DPDK_FIND_AND_FREE_UNUSED is called for each Memory segment lis= t (FBARRAY pointer is derived from MSL like below) > > dpdk_find_and_free_unused(const struct rte_memseg_list *msl= , > void *arg UNUSED) > { > Int ms_idx; > arr =3D (struct rte_fbarray *) &msl->memseg_arr; > > /* > * use size of 2 instead of 1 to find the next fr= ee slot but > * not hole. > */ > ms_idx =3D rte_fbarray_find_next_n_free(arr, 0, 2); > > if (ms_idx >=3D 0) { > addr =3D RTE_PTR_ADD(msl->base_va, ms_idx * msl-= >page_sz); > munmap(addr, RTE_PTR_DIFF(RTE_PTR_ADD(msl->ba= se_va, msl->len), addr)); > } > } You unmap memory, but you do not maintain DPDK memory management structures= , that is, DPDK does not know that this page is no longer usable. Probably this is the reason for the crash. You could print regions you're unmapping and the segfault address to confir= m. --_000_SJ0PR11MB4846972B8C726C51A8E39797DD519SJ0PR11MB4846namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Dmitry=

&nbs= p;

My answer= for your reply

&nbs= p;

You unmap memory, but you do not maintain DPDK memor= y management structures,
that is, DPDK does not know that this page is no longer usable.
Probably this is the reason for the crash.
You could print regions you're unmapping and the segfault address to confir= m.

&nbs= p;

[Uma] :&n= bsp; Yes we are unmapping the entire range hoping all are free inside DPDK = and DPDK heaps never use these pages.

&nbs= p;

Suppose w= e have 400 pages total free_hp, we want only 252 pages , so we reduce nr_pa= ges to 252.

&nbs= p;

So we ass= ume 253 to 400 inside DPDK are free as we nr_pages are made by my applicati= on as 252.

&nbs= p;

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-&= gt;base_va, msl->len), addr)/msl->page_sz); -> 253 comes (should b= e same as above)

ms_next_i= dx =3D  rte_fbarray_find_next_used(arr, ms_idx); -> This comes -1 a= s NO USED page is there (<0)

&nbs= p;

Hence we = call unmap like -> munmap(addr, RTE_PTR_DIFF(RTE_PTR_ADD(msl->base_va= , msl->len), addr));

&nbs= p;

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 applicatio= n, other than above 3 checks)

&nbs= p;

If it= =92s not safe to free, how to inform DPDK to free those pages in FBARRAY an= d also clean up its heap list so that it never crashes !!=

&nbs= p;

We are su= specting this code below  hits NULL crash or invalid address reference= for us

&nbs= p;

static st= ruct malloc_elem *

find_suit= able_element(struct malloc_heap *heap, size_t size,

  &n= bsp;             unsigned int flags, size_t a= lign, size_t bound, bool contig)

{

  &n= bsp;     size_t idx;

  &n= bsp;     struct malloc_elem *elem, *alt_elem =3D NULL;=

&nbs= p;

 =       for (idx =3D malloc_elem_free_list_index(size);<= /o:p>

 =                     &nbs= p; idx < RTE_HEAP_NUM_FREELISTS; idx++) {

  &n= bsp;             for (elem =3D LIST_FIRST(&heap->free_head[idx]);   -> W= e are suspecting elem is invalid address and hence crashed !!!!<= /b>

 =                     &nbs= p;         !!elem; elem =3D LIST_NEXT(elem, free_list))= {

  &n= bsp;                     = if (malloc_elem_can_hold(elem, size, align, bound,

  &n= bsp;                     =                 contig)) {

Thanks

Umakiran<= o:p>

&nbs= p;

&nbs= p;

From: Dmitry Kozlyuk <= dmitry.kozliuk@gmail.com>
Date: Thursday, 22 September 2022 at 2:31 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

Hi Umakiran,

> From: Umakiran Godavarthi (ugodavar) <ugodavar@cisco.com>
> Date: Wednesday, 14 September 2022 at 1:00 PM
[...]
>   1.  Then we go to DPDK Memory segment list walkthroug= h and for each FBARRAY , we find the used pages by DPDK and unmap the remai= ning pages by below code (Idea is to free the huge pages taken by DPDK proc= ess virtual memory) -> Free_HP will be 0 then, as X pages are used by DPDK and all unnecessary pages are freed in this step)=
> Sample Code of 4 :
>
>            = ;   rte_memseg_list_walk_thread_unsafe(dpdk_find_and_free_unused,= NULL); ->DPDK_FIND_AND_FREE_UNUSED is called for each Memory segment li= st (FBARRAY pointer is derived from MSL like below)
>
>            = ;   dpdk_find_and_free_unused(const struct rte_memseg_list *msl,<= br> >            = ;            &n= bsp;            = ;      void *arg UNUSED)
>            = ;    {
>            = ;           Int ms_idx; >            = ;            arr =3D= (struct rte_fbarray *) &msl->memseg_arr;
>
>            = ;             /= *
>            = ;            &n= bsp; * use size of 2 instead of 1 to find the next free slot but
>            = ;             *= not hole.
>            = ;             *= /
>            = ;          ms_idx =3D rte_fbar= ray_find_next_n_free(arr, 0, 2);
>
>            = ;          if (ms_idx >=3D = 0) {
>            = ;            &n= bsp; addr =3D RTE_PTR_ADD(msl->base_va, ms_idx * msl->page_sz);
>            = ;            &n= bsp;    munmap(addr, RTE_PTR_DIFF(RTE_PTR_ADD(msl->base_v= a, msl->len), addr));
>            = ;           }
>            = ;    }

You unmap memory, but you do not maintain DPDK memory management structures= ,
that is, DPDK does not know that this page is no longer usable.
Probably this is the reason for the crash.
You could print regions you're unmapping and the segfault address to confir= m.

--_000_SJ0PR11MB4846972B8C726C51A8E39797DD519SJ0PR11MB4846namp_--