From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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)" <ugodavar@cisco.com>
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
CC: "anatoly.burakov@intel.com" <anatoly.burakov@intel.com>, "dev@dpdk.org"
<dev@dpdk.org>, "stephen@networkplumber.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: <SJ0PR11MB4846972B8C726C51A8E39797DD519@SJ0PR11MB4846.namprd11.prod.outlook.com>
References: <SJ0PR11MB484677B272ABA8D4C336925CDD469@SJ0PR11MB4846.namprd11.prod.outlook.com>
<SJ0PR11MB484618A355C51F501B8EC03CDD4F9@SJ0PR11MB4846.namprd11.prod.outlook.com>
<SJ0PR11MB484677FEEE61AD8CF101875CDD4E9@SJ0PR11MB4846.namprd11.prod.outlook.com>
<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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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 <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 <de=
v@dpdk.org>, stephen@networkplumber.org <stephen@networkplumber.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 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
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of=
fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang=3D"EN-IN" link=3D"#0563C1" vlink=3D"#954F72" style=3D"word-wrap:=
break-word">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">Hi Dmitry=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">My answer=
for your reply<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal">You unmap memory, but you do not maintain DPDK memor=
y management structures,<br>
that is, DPDK does not know that this page is no longer usable.<br>
Probably this is the reason for the crash.<br>
You could print regions you're unmapping and the segfault address to confir=
m.<o:p></o:p></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">[Uma] :&n=
bsp; Yes we are unmapping the entire range hoping all are free inside DPDK =
and DPDK heaps never use these pages.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">Suppose w=
e have 400 pages total free_hp, we want only 252 pages , so we reduce nr_pa=
ges to 252.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">So we ass=
ume 253 to 400 inside DPDK are free as we nr_pages are made by my applicati=
on as 252.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">ms_idx =
=3D rte_fbarray_find_next_n_free(arr, 0, 2); -> 253 comes<o:p></o:p></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">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)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">ms_next_i=
dx =3D rte_fbarray_find_next_used(arr, ms_idx); -> This comes -1 a=
s NO USED page is there (<0)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">Hence we =
call unmap like -> munmap(addr, RTE_PTR_DIFF(RTE_PTR_ADD(msl->base_va=
, msl->len), addr));<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><b><span style=3D"mso-fareast-language:EN-US">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)<o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><b><span style=3D"mso-fareast-language:EN-US">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 !!<o:p></o:p></span>=
</b></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">We are su=
specting this code below hits NULL crash or invalid address reference=
for us<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">static st=
ruct malloc_elem *<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">find_suit=
able_element(struct malloc_heap *heap, size_t size,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"> &n=
bsp; unsigned int flags, size_t a=
lign, size_t bound, bool contig)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">{<o:p></o=
:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"> &n=
bsp; size_t idx;<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"> &n=
bsp; struct malloc_elem *elem, *alt_elem =3D NULL;<o:p></o:p>=
</span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><b><span style=3D"mso-fareast-language:EN-US"> =
for (idx =3D malloc_elem_free_list_index(size);<o:p><=
/o:p></span></b></p>
<p class=3D"MsoNormal"><b><span style=3D"mso-fareast-language:EN-US"> =
&nbs=
p; idx < RTE_HEAP_NUM_FREELISTS; idx++) {<o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"> &n=
bsp; <b>
for (elem =3D LIST_FIRST(&heap->free_head[idx]); -> W=
e are suspecting elem is invalid address and hence crashed !!!!<o:p></o:p><=
/b></span></p>
<p class=3D"MsoNormal"><b><span style=3D"mso-fareast-language:EN-US"> =
&nbs=
p; !!elem; elem =3D LIST_NEXT(elem, free_list))=
{<o:p></o:p></span></b></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"> &n=
bsp; =
if (malloc_elem_can_hold(elem, size, align, bound,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"> &n=
bsp; =
contig)) {<o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p></o:=
p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">Thanks<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US">Umakiran<=
o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"mso-fareast-language:EN-US"><o:p>&nbs=
p;</o:p></span></p>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"fon=
t-size:12.0pt;color:black">From:
</span></b><span style=3D"font-size:12.0pt;color:black">Dmitry Kozlyuk <=
dmitry.kozliuk@gmail.com><br>
<b>Date: </b>Thursday, 22 September 2022 at 2:31 PM<br>
<b>To: </b>Umakiran Godavarthi (ugodavar) <ugodavar@cisco.com><br>
<b>Cc: </b>anatoly.burakov@intel.com <anatoly.burakov@intel.com>, dev=
@dpdk.org <dev@dpdk.org>, stephen@networkplumber.org <stephen@netw=
orkplumber.org><br>
<b>Subject: </b>Re: DPDK 19.11.5 Legacy Memory Design Query<o:p></o:p></spa=
n></p>
</div>
<div>
<p class=3D"MsoNormal">Hi Umakiran,<br>
<br>
> From: Umakiran Godavarthi (ugodavar) <ugodavar@cisco.com><br>
> Date: Wednesday, 14 September 2022 at 1:00 PM<br>
[...]<br>
> 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)=
<br>
> Sample Code of 4 :<br>
> <br>
>  =
; 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)<br>
> <br>
>  =
; dpdk_find_and_free_unused(const struct rte_memseg_list *msl,<=
br>
>  =
; &n=
bsp;  =
; void *arg UNUSED)<br>
>  =
; {<br>
>  =
; Int ms_idx;<b=
r>
>  =
; arr =3D=
(struct rte_fbarray *) &msl->memseg_arr;<br>
> <br>
>  =
; /=
*<br>
>  =
; &n=
bsp; * use size of 2 instead of 1 to find the next free slot but<br>
>  =
; *=
not hole.<br>
>  =
; *=
/<br>
>  =
; ms_idx =3D rte_fbar=
ray_find_next_n_free(arr, 0, 2);<br>
> <br>
>  =
; if (ms_idx >=3D =
0) {<br>
>  =
; &n=
bsp; addr =3D RTE_PTR_ADD(msl->base_va, ms_idx * msl->page_sz);<br>
>  =
; &n=
bsp; munmap(addr, RTE_PTR_DIFF(RTE_PTR_ADD(msl->base_v=
a, msl->len), addr));<br>
>  =
; }<br>
>  =
; }<br>
<br>
You unmap memory, but you do not maintain DPDK memory management structures=
,<br>
that is, DPDK does not know that this page is no longer usable.<br>
Probably this is the reason for the crash.<br>
You could print regions you're unmapping and the segfault address to confir=
m.<o:p></o:p></p>
</div>
</div>
</body>
</html>
--_000_SJ0PR11MB4846972B8C726C51A8E39797DD519SJ0PR11MB4846namp_--