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 8596FA00C2; Mon, 26 Sep 2022 15:06:59 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 917964114B; Mon, 26 Sep 2022 15:06:55 +0200 (CEST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by mails.dpdk.org (Postfix) with ESMTP id 9D35940695 for ; Mon, 26 Sep 2022 15:06:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37431; q=dns/txt; s=iport; t=1664197613; x=1665407213; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=P0JpdTPqJuQMkWv+OqL8sQe4wZaQnvNMSA7LrTcq0x4=; b=XNIaQ+mOznsYAHsbf/3NgEWyjIL8ThmQ8tKA6xWedATwq8Tbe+bbBh4w BLSvqO0foh+sfuqUbxxgt991hhUcLM67S6jAjYJ5VvHaPMpZhOSgKLYq2 CAvV+ONco6ckG+J5Flg7Tck+T8E/fTkbeCvTnplN0zfqYYjbRQOka7zsa w=; X-IPAS-Result: =?us-ascii?q?A0AlAgD0ojFjmIsNJK1aHgEBCxIMQIFEC4EhMVJ/Alk6R?= =?us-ascii?q?YgaA4UviBYDgROKGJA7gSyBJQNUCwEBAQ0BATsHBAEBhQUChGwCJTQJDgECB?= =?us-ascii?q?AEBAQEDAgMBAQEBAQEDAQEFAQEBAgEHBBQBAQEBAQEBAR0ZBQ4QJ4VoDYZCA?= =?us-ascii?q?QEBAQIBEhsTAQE3AQQLAgEIEQMBAiEBBgchERQJCAIEDgUIDA6CWwGCFlcDD?= =?us-ascii?q?SMDAQ+dLwGBPwKKH3iBNIEBgggBAQYEBIFOAw8vgwINC4I4CYE9gzKDUYFGg?= =?us-ascii?q?TyCBYQfJxyBSUSBFAFDgjA3PoIgQgEDgWAeBgcJg1iCLoQHlRUHNwNEHUEDC?= =?us-ascii?q?0I1GAMUAwUkBwMZDyMNDQQWBwwDAwUlAwICGwcCAgMCBhMFAgJNNggECAQrJ?= =?us-ascii?q?A8FAgcvBQQvAh4EBQYRCAIWAgYEBAQEFQIQCAIIJhcHEzMZAQVZEAkhHA4aD?= =?us-ascii?q?QUGEwMgbwVEDygxaysdGwqBDCooFQMEBAMCBhMDAyICECoxFAQpExItBytzC?= =?us-ascii?q?QIDImcFAwMEKCwDCSAEHAcoJjwHWDoBBAMCECI9BgMJAwIkW4EvKAUDDRkmC?= =?us-ascii?q?AUjFx4ECDwCBQZXEwIKEgMTlxqBQYEwLi2BAicIDgEBFwt+JQgdRwwLL5F6F?= =?us-ascii?q?I4KoE1uCoNZizuOd4YhFoN2jFCYPpcLjTyDZ5EDDoUMAgQCBAUCDgEBBoFOE?= =?us-ascii?q?zqBW3AVgyIJSBkPjiAMDQmDUIUUhUp1AgEIMAIGCwEBAwmKVgEB?= IronPort-PHdr: A9a23:XztoNhXAV6VQnpQqLGJ667ggbQPV8K36AWYlg6HPw5pCcaWmqpLlO kGXpfBgl0TAUoiT7fVYw/HXvKbtVS1lg96BvXkOfYYKW0oDjsMbzAAlCdSOXEv8KvOiZicmH cNEAVli+XzzMUVcFMvkIVPIpXjn5j8JERK5Pg1wdYzI IronPort-Data: A9a23:rCKiFaJD4wyP9SGIFE+RFJUlxSXFcZb7ZxGr2PjKsXjdYENShDwDn GUXWTzUb6mDNDDxLd0lOtnk/EIG7ZXcxtA3T1Ed+CA2RRqmiyZq6fd1j6vUF3nPRiEWZBs/t 63yUvGZcIZsCCW0Si6FatANl1EkvU2zbue6WbWs1hxZH1c+En9w00w7wobVv6Yx6TSHK1LV0 T/Ni5W31G+Ng1aY5UpNtspvADs21BjDkGtwUm4WPJinj3eC/5UhN6/zEInqR5fOria4KcbhL wrL5OnREmo0ZH7BAPv9+lrwWhVirrI/oWFih1IOM5VOjCSuqQQMz7k9OfZDRnx4tDCWo9Np8 +5Qi5mZHFJB0q3kwIzxUjFRFyV4eKZB4rKCfz60sNeYyAvNdH6EL/dGVR5te9ZGvL8sRzgVp JT0KxhVBvyHr/+5x76yVOB2rs8iN8LseogYvxmMyBmIVaZ7GcqdEvyiCdlw5Rw2gu8QPeTkO e05SQROUEvqSgZKEwJCYH45tL742iagG9FCk3qOuacv42XV5Ap8zKfqKtnNfsGPT8hP2EGCq Qru82nnKh0CON/ZziCKmlqlgObTmifqHogPDrS78eBCgVuPy2hVAxoTPXO3pPilkF/4WNVNL 00J+QIhqKEz8AqgSdyVYvGjiHeAuhhZUN1KHqhkrgqM0aHTpQ2eAwDoUwKtdvQYqdAwSDB1+ WSmoNb2OT93i4aId3e0o+L8QSyJBQAZKmoLZCkhRAQD4sX+rIxbsv4pZos5eEJSpoCocQwc0 wxmvwBl3OxK0pBjO7GTuAGZ3W39//AlWyZvvm3qsnSZAhSVjWJPT6Ws7VXdhRqrBNnEFgDa1 JTodjT30QzjJZiJkCrIS+IXEfT3of2EKzbbx1VoGvHNFghBGVb9JOi8Axkney+F1/ronxeyO Sc/XisKvvdu0IOCN/MfXm5II51CIVLcPdrkTOvISdFFf4J8cgSKlAk3OxDMhju1zhNwyPFlU Xt+TSpKJStHYUiA5GfmL9rxLZd3rszD7TqJHMuin0jPPUS2NCLFIVv6DLd+RrlpsPzbyOkk2 91eLMCNgw5OS/HzZzK/zGLgBQ5iEJTPPriv85Y/XrfaemJOQTh9Y9ePmulJU9I+wMxoehLgo yvVtrlwkgSv3BUq6GyiNxheVV8Ydcsl/CNmbHJ8Yj5FGRELOO6S0UvWTLNvFZFPyQCp5aUco yUtEylYPslydw== IronPort-HdrOrdr: A9a23:SIMXNKp7Te/9J1I+5LcOPZAaV5uVL9V00zEX/kB9WHVpm5Oj+f xGzc516farslossSkb6Ky90KnpewK5yXcH2/hvAV7CZniqhILMFuBfBOTZskXd8kHFh4xgPO JbAtVD4b7LfBRHZKTBkXKF+r8bqbHtms3J9ITjJjVWPHtXgspbnmBE43OgYzRLrX59dPwE/f Snl696jgvlXU5SQtWwB3EDUeSGjcbMjojabRkPAANiwBWSjBuzgYSKXCSw71M7aXdi0L0i+W /Kn0jS/aO4qcy2zRfayiv684lWot380dFObfb8xPT9aw+cyzpAVr4RGIFqjwpF4t1HL2xa1e Ukli1Qf/ibLUmhOl1d7yGdnDUImwxelUMKgWXo8EcL5/aJAg7Tz6F69Npkmtyz0Tt4gDg06t M640uJ85VQFh/OhyL7+pzBUAxrjFO9pT44nfcUlGE3a/pXVFZ9l/1owKpuKuZIIAvqrIQ8VO V+BsDV4/hbNVuccnDCp2FqhNihRG46EBuKSlUL/pX96UkdoFlpi08DgMAPlHYJ85wwD5FC+u TfK6xt0LVDVNUfY65xDPoIBcG3FmvOSxTRN3/6GyWtKIgXf3bW75Ln6rQ84++nPJQO0ZspgZ zEFEhVsGYjEniefvFmHKc7hiwlbF/NKAgFkPsulKSRkoeMNobWDQ== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.93,346,1654560000"; d="scan'208,217";a="908502691" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Sep 2022 13:06:52 +0000 Received: from mail.cisco.com (xfe-aln-001.cisco.com [173.37.135.121]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 28QD6qRP014612 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2022 13:06:52 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9; Mon, 26 Sep 2022 08:06:51 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) 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 via Frontend Transport; Mon, 26 Sep 2022 08:06:51 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I8ZVivGpka00HRjzSs8hBeUZ/w/TAKnQYONJ9SvC5gjZWOlceG2e8HtYwl5njLt84d5HR8zDSGYxh/ydZNDc/FbP+TLCZO3vSvvW9QMtehmUvuJc6Ne829wnP5pu185j587tSaaMVOoheb4yZihimQDtt6QgdS4SBuVeNnEi4xwQl5l5AyeVsejSWYN2tK8qK7tDDpPTtDbO1hzpD+OkEQwo1IhPpIn7FL6/U0rBQM+vfDboYOKsEWtWQUbdGktLxO3e98RZtb3reQq48nU+oBS+DhtyzQHxcyQrgGs1/WGnHyNRnMTvin92bshE8yzdeCoEjr566syx2uqBJ09aRA== 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=56aD3eG2bd/WYnojiAZrFSCZptyeIkKUmJ+5Q9iKJpI=; b=BVp7h9jloYmzlCCcrSmXC9/GWEZ84auNwOkhySJ/AiYjDT8oNGvBngPGaFAJBXyyMW05v2B7ehxRCDXpq+Lkidxqnbg2LNQi6ROzn3p7MsVEJNO0kOr/Ye73t1hH1cNKaTg+65dxmShEJgxkTBtezA6xR0mQQuS58PUbHO+n9ngPkJxqOf3NTNu06Dejmwf0k0p8DTr5oXweXzjFnP8haDRnz7C75nYOdr5t4Cfp50BWI3anI/09HDQIAfGApEqvSIfWezgVUK60I4F/t9iDzqXClZqntDQs5SlRDNgUPTceD1ouA8REN7aJxHPApsIR/E5qMydRzkIY3/u5g4FP4Q== 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=56aD3eG2bd/WYnojiAZrFSCZptyeIkKUmJ+5Q9iKJpI=; b=spy2ZShFR4YGCIhhUm6B9a/w5h0TcGfmvcauzQdvnQG2S+/ToU2N7yqd9qkwqDZMNjjcPmFPJKa81JSw2UK6c/STGFL4wYXW6ZKQ1OXvjJYa2p2tLBtquaP+JGy0urHFlQIh9Av96N7MwHDgGcf4vkJnPfpXVRNSM6bPN8x5A34= Received: from SJ0PR11MB4846.namprd11.prod.outlook.com (2603:10b6:a03:2d8::24) by DM4PR11MB6142.namprd11.prod.outlook.com (2603:10b6:8:b2::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.25; Mon, 26 Sep 2022 13:06:50 +0000 Received: from SJ0PR11MB4846.namprd11.prod.outlook.com ([fe80::bf52:6035:504a:808c]) by SJ0PR11MB4846.namprd11.prod.outlook.com ([fe80::bf52:6035:504a:808c%8]) with mapi id 15.20.5654.026; Mon, 26 Sep 2022 13:06:50 +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/TnQXrtK3pfBK4gAGoheSAAA73AIABtqxUgAAKNICAAAVZ9oAAEfuAgASvCUiAAAYQIA== Date: Mon, 26 Sep 2022 13:06:49 +0000 Message-ID: References: <20220922120052.710c2cd1@sovereign> <20220923144727.155be566@sovereign> <20220923161057.0205e703@sovereign> In-Reply-To: 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_|DM4PR11MB6142:EE_ x-ms-office365-filtering-correlation-id: 28f72e25-2084-418a-d56e-08da9fbff982 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: J1y4DQ3sczOIio9XdOSombNXlWhhaofghDZSF0Dcvx4Ql4I5IWsrmANUb9vCiMgHBa2Z5Lzo1WQ91hld0XM0reiBxmvGZbmltH0zf/I4U/puogvPlxK4WceLfMfCn7xTDa+fvTkbwYSwugj1m62VXPZ7wLtyEM4Rc5NZw1Lc5z4LMH/IQe4kSCHUSrYNM9Maa98PtaO7BIC/7lAb/8C+BS18eU/lHAxLaKbjCuF+Cj0zgUIRAyqWvLTieoQndn6q4Z+JqOkfwBdcg2RyBL09hO0l+aVbOLsjOhydgj1LJ9IZKtewH4dXIqOIvfG/WbG7H79Gl/ikLwpc/mO51AkNdJYzaZWMbgD2hDpU0Gmh/FT/w3f1lZ/MBbdSKLSOVQu1gSUMrzr3L7q832sMLNqLcZBcRuKpRwxbA+yW3M6koguQsouMUmqLh3i0lK4YNdZvm8MgC7T8plls1/nbMZFriudgt6b+/aKWp38tpHC9dP3fjinNeCgGvf8SeXnyl4Jsm3WPJedTFGjF59u47NNK9RwyFU4osqQvSnNdj9wzaUM1og0/M4W15RvAfqsCvF6EWh/GM0oQX2n63F3TzPMofZ4bg+ftFBHX92fYVkJN9BTRnSmdGV2NYTUtfxqw9p6YHGGRlParlHnfOIw+flOLI5hL6jalxUoRiSTpLpG61XsmhOPOswuG+iyLC1tUjGXC96dXg0gr1H3K5ipkqjoEvKvZtbUOBiZMQ4cuGUPcEI1rcMWdShFo4E3AkkwOT0nzC8B5Whches4HAtbvkJWyzupGtL0yj8WV6thJ6Zpx5ODrGbyMgpSpNYq9dYa5eg84JpwHxsXsZCKflZKdE4vUNw== 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)(376002)(136003)(39860400002)(366004)(396003)(346002)(451199015)(6506007)(53546011)(7696005)(478600001)(966005)(41300700001)(71200400001)(55236004)(2940100002)(9686003)(83380400001)(186003)(2906002)(26005)(5660300002)(55016003)(6916009)(54906003)(8936002)(66446008)(66946007)(52536014)(76116006)(66476007)(66556008)(91956017)(64756008)(4326008)(8676002)(316002)(166002)(38100700002)(86362001)(122000001)(38070700005)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?HigUq823IeTBMtnrgvieOe4xvCxUVNAX3YrIKmeamJCfqooEcBuao5DF?= =?Windows-1252?Q?YW/NSjdtDzALtclSSlrN6CeVdrSrlKPRAAhHUbwLh+s/axeyJ2Q7IBBU?= =?Windows-1252?Q?mqIw77cXclEYe15D6TEV6U2OZKw+nkXwjwRAbwSKRCevjaXIESINI+TE?= =?Windows-1252?Q?wg1DEMxjzyiq4gs2FBMSJMxBpzXXb0SphfJQToS6bAikdeu6zz3ADnwB?= =?Windows-1252?Q?SlHpmGsTX/vJZJiNzfthqHfY7AK5ym4vBLenZ2FQuCq6MtsdUmVjgvyF?= =?Windows-1252?Q?K5w+t3sVDNexhzBG+LtFvwzdWCVyvwILUcDGNhE5Zi8jvRrCTakLRWgP?= =?Windows-1252?Q?7BwTUBFpyI7SJyF4KJhhusIQUM4Gxm8hCFk4LhLc+mvx35Ab5pF5bMlF?= =?Windows-1252?Q?afdzNify1jGsXnCMvZoK+h8gIJq+Ztzm94eXGebmN0lMHJN/yZbSBF9g?= =?Windows-1252?Q?uJDNpqGL7hZf86qQEbMB9djRoYoNmdVzxsC4BVVNm0SY4qMmOerr2NJk?= =?Windows-1252?Q?TX9V7qT1cO7BStcgqDaf69qdixxeiasQClQ3xWf2cnKeciOFrv4U4R5e?= =?Windows-1252?Q?makkR/s1VjRA+rrmneQyvQ1PG1cY3yj/wbLzvTbVwlWH9MSFIEMwmhsX?= =?Windows-1252?Q?/F3V5qvoRwKI8QHVu+qNXV3V3uxpVeS8o625y/mNZoeD4BUEgFzc9nw8?= =?Windows-1252?Q?1M3NTSwk3yHW2CbFtAdFtDY2R8+kFeZj26NhkuuTwg8fagthDZGEg18G?= =?Windows-1252?Q?nUX5/JPWR3WUWrAzgI6fqdJID0KTJHSUbjL5N6C/XZYRmh90lrWez49i?= =?Windows-1252?Q?2HnrIegQ84xeN5UP1Slzl/NKSx+oS35+A2VBFmkxbQ/1DvjY/EHgPWFa?= =?Windows-1252?Q?dysMEuMDyB0MBqwEtTrnw5pmSMkxNsE7nKJcKD+Dza1OgM7ZUkw5431U?= =?Windows-1252?Q?J73nBBmU60o+0Lh/km6NxxBuvXnmPZ/gZApUv7LCwkZryJyQ0rSE0kIN?= =?Windows-1252?Q?ynwioGvPtVzS6W35D0drOU8aaHFGIjkNlFXL6FeEyxrb0e41Nj7BiVpR?= =?Windows-1252?Q?/kaEFK7kZ9wm3vWHyYBN8x+hP6cXMjp/NksXhHqcr7PLQjIOxARqHFfJ?= =?Windows-1252?Q?fIWKhQuGFyURHGI+gyZLuuTWq+W+M478F5qXu+NjH2mOjb/G6OIsxltq?= =?Windows-1252?Q?9gNfipaMWsgRccF+pJUvYYBLuRqUSOpkEKnfuTJU1lptc9TsUDNybnvC?= =?Windows-1252?Q?fpcYexLhkjIWWeDWNSQk5vUwDGIBH9HDj6wsDLdL5bSvLhNmRRO7Y4Vu?= =?Windows-1252?Q?YKymuaq49Y/OMtKIc+77en5OGm5Oa7IgFYdi7kbf6gtEpdX6ZIA0A2cP?= =?Windows-1252?Q?uAsbB3PMAHtZYwD9pAQIaUSZJBgJ9lNnD1SEWrd1PtNfBG7nVk6NBHhz?= =?Windows-1252?Q?BSJW6HcMfPcQ1t14Xa61787Ehpr1sacmy8alHrNuRF9rBJBbxDpktbk0?= =?Windows-1252?Q?Cf1n4Eab1wl51NbBEYyayk/SyU1xzQg8lCrhuYdGwtpQXboWrrkfs0QD?= =?Windows-1252?Q?syLXWbIcF/NwSLK28i9WrnJeS61CEVjU6bVydOzxVojU4SqkWwLyrW6b?= =?Windows-1252?Q?6vl7H98KUE7Nhl7JGUzLmd5UgTigXyXFszB7b8Z6nvYlnBWVM4dkvCVH?= =?Windows-1252?Q?sSBM2pTGnPzJM9JTKfVyr7a+cMJml3PfT95i2tlaSACDaa3uVqAhXw?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_SJ0PR11MB4846BFEEFAA89FC9695F0097DD529SJ0PR11MB4846namp_" 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: 28f72e25-2084-418a-d56e-08da9fbff982 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2022 13:06:49.9392 (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: wpH7Y1pNjLnRTrH8DBPNtabVl21GCQoAyG0RBd9XOhKew2EwFa2ade7ySB6DnhbaP7qd3mDlk+x4s7mnvSqW1w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB6142 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.135.121, xfe-aln-001.cisco.com X-Outbound-Node: alln-core-6.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_SJ0PR11MB4846BFEEFAA89FC9695F0097DD529SJ0PR11MB4846namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Dimitry We know If the application does unmap, DPDK native heaps are not getting cl= eaned up in =93native: use regular DPDK memory=94 memory type. Can we get an API from DPDK community please to clean up the heaps given th= e VA and length to be freed ? Like below https://doc.dpdk.org/api/rte__memory_8h.html#afb3c1f8be29fa15953cebdad3a9cd= 8eb int rte_extmem_unregister ( void * va_addr, size_t len ) Unregister external memory chunk with DPDK. Note Using this API is mutually exclusive with rte_malloc family of API's. This API will not perform any DMA unmapping. It is expected that user will = do that themselves. Before calling this function, all other processes must call rte_extmem_deta= ch to detach from the memory area. Parameters va_addr Start of virtual area to unregister len Length of virtual area to unregister Returns =B7 0 on success =B7 -1 in case of error, with rte_errno set to one of the following= : EINVAL - one of the parameters was invalid ENOENT - memory chunk was not If we get such API in native way , it will be good for us instead of changi= ng the design and going all the way writing code for new memory type Please suggest us can we get an API to clean up DPDK NATIVE POOLS if VA_ADD= R and LEN is given ? Thanks Umakiran From: Umakiran Godavarthi (ugodavar) Date: Monday, 26 September 2022 at 6:25 PM To: Dmitry Kozlyuk Cc: anatoly.burakov@intel.com , dev@dpdk.org , stephen@networkplumber.org Subject: Re: DPDK 19.11.5 Legacy Memory Design Query Thanks @Dmitry Kozlyuk for your suggestion= s I will try the following for DPDK pool creation My logic of calculating MBUF=92s remains same Saw this code in DPDK testpmd where External heap memory is used case MP_ALLOC_XMEM_HUGE: { int heap_socket; bool huge =3D mp_alloc_type =3D=3D MP_ALLOC_XMEM_HU= GE; if (setup_extmem(nb_mbuf, mbuf_seg_size, huge) < 0) rte_exit(EXIT_FAILURE, "Could not create ex= ternal memory\n"); heap_socket =3D rte_malloc_heap_get_socket(EXTMEM_HEAP_NAME= ); if (heap_socket < 0) rte_exit(EXIT_FAILURE, "Could not get exter= nal memory socket ID\n"); TESTPMD_LOG(INFO, "preferred mempool ops selected: = %s\n", rte_mbuf_best_mempool_ops()); rte_mp =3D rte_pktmbuf_pool_create(pool_name, nb_mb= uf, mb_mempool_cache, 0, mbuf_seg_size, heap_socket); break; } So I will do the same 1. EAL Init 2. Calculate MBUF we need for our application 3. Then create pool using MP_ALLOC_XEM_HUGE 1,2,3 should work right , that should avoid heap corruption issues right ? We have total 3 types pool creation /* * Select mempool allocation type: * - native: use regular DPDK memory * - anon: use regular DPDK memory to create mempool, but populate using * anonymous memory (may not be IOVA-contiguous) * - xmem: use externally allocated hugepage memory */ Instead of Freeing unused virtual memory in DPDK native way, we just create= a pool with type XMEM_HUGE and add page by page to it like testpmd code Please let me know 1,2,3 steps are good right, so we need to boot DPDK with= socket mem --socket-mem 2048 so that DPDK takes only 1 page natively and boots up righ= t ? Thanks Umakiran From: Dmitry Kozlyuk Date: Friday, 23 September 2022 at 6:41 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 12:12 (UTC+0000), Umakiran Godavarthi (ugodavar): > [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. > 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 adding later on pages ? (rte_extmem_*, can you = please give the full API details and how to call it with arguments ) Guide: https://doc.dpdk.org/guides-19.11/prog_guide/env_abstraction_layer.html= #support-for-externally-allocated-memory I recommend reading the entire section about DPDK memory management since you're going to use an uncommon API and should understand what's going on. API (the linked function and those following it): http://doc.dpdk.org/api-19.11/rte__malloc_8h.html#a2295623c85ba41fe5bf7= dce6bf0393d6 http://doc.dpdk.org/api-19.11/rte__memory_8h.html#a653510fb0c58bf63f547= 08677e3a2eba > We can do 1,2,3 there is a problem once we reduce pages to 1 , kernel wil= l free the huge pages totally > > So is there a way not to touch NR_HP, FREE_HP, and just pass arguments to= boot DPDK with just 1 page ? Please let us know and later add pages we nee= d to DPDK !! See --socket-mem EAL option: http://doc.dpdk.org/guides-19.11/linux_gsg/linux_eal_parameters.html#id= 3 > 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 fo= r both processes. We have to stick to legacy memory design only for now !! Sorry, I still don't understand. Virtual and physical addresses of DPDK memory are the same across processes in both legacy and dynamic memory mode. --_000_SJ0PR11MB4846BFEEFAA89FC9695F0097DD529SJ0PR11MB4846namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Dimitr= y

&nbs= p;

We know I= f the application does unmap, DPDK native heaps are not getting cleaned up =  in =93native: use r= egular DPDK memory=94  memory type.

&nbs= p;

Can we ge= t an API from DPDK community please to clean up the heaps given the VA and = length to be freed ? Like below

&nbs= p;

https://doc.dpdk.org/api/rte__memory_8h.html#afb3c1f8be29fa15953ce= bdad3a9cd8eb

&nbs= p;

int rte_ext= mem_unregister

(

void * 

va_addr= ,

size_t 

len 

)

 

Unregist= er external memory chunk with DPDK.

Note

Using this = API is mutually exclusive with rte_malloc family of API's.

This API wi= ll not perform any DMA unmapping. It is expected that user will do that the= mselves.

Before call= ing this function, all other processes must call rte_extm= em_detach to detach from the memory area.

Paramete= rs

va_addr=

Start of virtual area to unregister=

len

Length of virtual area to unregister

Returns<= o:p>

=B7         0 on success

=B7         -1 in case of error, with rte_errno set to one of the f= ollowing: EINVAL - one of the parameters was invalid ENOENT - memory chunk = was not

If we get= such API in native way , it will be good for us instead of changing the de= sign and going all the way writing code for new memory type

&nbs= p;

Please su= ggest us can we get an API to clean up DPDK NATIVE POOLS if VA_ADDR and LEN= is given ?

&nbs= p;

Thanks

Umakiran<= o:p>

&nbs= p;

&nbs= p;

From: Umakiran Godavarthi= (ugodavar) <ugodavar@cisco.com>
Date: Monday, 26 September 2022 at 6:25 PM
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@netw= orkplumber.org>
Subject: Re: DPDK 19.11.5 Legacy Memory Design Query

Thanks @Dmitry Kozlyuk for your suggestions

 

I will tr= y the following for DPDK pool creation

 

My logic = of calculating MBUF=92s remains same

 

Saw this = code in DPDK testpmd where External heap memory is used

 

case MP_A= LLOC_XMEM_HUGE:

  &n= bsp;             {

  &n= bsp;                     = int heap_socket;

  &n= bsp;                     = bool huge =3D mp_alloc_type =3D=3D MP_ALLOC_XMEM_HUGE;

 

 =                     &nbs= p; if (setup_extmem(nb_mbuf, mbuf_seg_size, huge) < 0)

  &n= bsp;                     =         rte_exit(EXIT_FAILURE, "Could not create e= xternal memory\n");

 

  &n= bsp;                     = heap_socket =3D

  &n= bsp;                     =         rte_malloc_heap_get_socket(EXTMEM_HEAP_NAME);

  &n= bsp;                     = if (heap_socket < 0)

  &n= bsp;                     =         rte_exit(EXIT_FAILURE, "Could not get exte= rnal memory socket ID\n");

 

  &n= bsp;                     = TESTPMD_LOG(INFO, "preferred mempool ops selected: %s\n",<= o:p>

  &n= bsp;                     =                 rte_mbuf_best_mempo= ol_ops());

 =                     &nbs= p; rte_mp =3D rte_pktmbuf_pool_create(pool_name, nb_mbuf,

 =                     &nbs= p;                 mb_mempool_cache= , 0, mbuf_seg_size,

 =                     &nbs= p;                 heap_socket);

  &n= bsp;                     = break;

  &n= bsp;             }

 

So I will= do the same

 

  1. EAL Init=
  2. Calculate MBUF we nee= d for our application
  3. Then create pool using MP_ALLOC_XEM_HUGE

 

1,2,3 sho= uld work right , that should avoid heap corruption issues right ?

 

We have t= otal 3 types pool creation

 

/*=

 * S= elect mempool allocation type:

 * -= native: use regular DPDK memory

 * -= anon: use regular DPDK memory to create mempool, but populate using=

 * &= nbsp;       anonymous memory (may not be IOVA-contiguous)

 = * - xmem: use externally allocated hugepage memory

 */<= /span>

 

Instead o= f Freeing unused virtual memory in DPDK native way, we just create a pool w= ith type XMEM_HUGE and add page by page to it like testpmd code=

 

Please le= t me know 1,2,3 steps are good right, so we need to boot DPDK with socket m= em

 

--socket-mem 2048 so that DPDK takes only 1 page natively and b= oots up right ?

 

Thanks

Umakiran

 

 

From: Dmitry Kozlyuk <= dmitry.kozliuk@gmail.com>
Date: Friday, 23 September 2022 at 6:41 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 12:12 (UTC= +0000), Umakiran Godavarthi (ugodavar):
> [Uma] :  Yes I agree if free_hp =3D 400, nr_hp =3D 252, we are ex= pecting DPDK takes only 252 and keep the remaining pages free in its heap.<= br> >            = ;    As you have mentioned just boot DPDK with 1 page, and a= dd 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 adding later on pages ? (rte_= extmem_*, can you please give the full API details and how to call it with = arguments )

Guide:

    https://doc.dpdk.org/guides-19.11/prog_guide/env_abstraction_layer.html#sup= port-for-externally-allocated-memory

I recommend reading the entire section about DPDK memory management
since you're going to use an uncommon API
and should understand what's going on.

API (the linked function and those following it):

    http://doc.dpdk.org/api-19.11/rte__malloc_8h.html#a2295623c85ba41fe5bf7dce6= bf0393d6

    http://doc.dpdk.org/api-19.11/rte__memory_8h.html#a653510fb0c58bf63f5470867= 7e3a2eba

> 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 boot DPDK with just 1 page ? Please let us know and later add pages we = need to DPDK !!

See --socket-mem EAL option:

    http://doc.dpdk.org/guides-19.11/linux_gsg/linux_eal_parameters.html#id3

> 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 proce= ss mapped page by page to primary process , and physical addr space is same= for both processes.  We have to stick to legacy memory design only fo= r now !!

Sorry, I still don't understand.
Virtual and physical addresses of DPDK memory are the same across processes=
in both legacy and dynamic memory mode.

--_000_SJ0PR11MB4846BFEEFAA89FC9695F0097DD529SJ0PR11MB4846namp_--