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 7999AA00C2; Mon, 26 Sep 2022 14:55:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5D28E4069B; Mon, 26 Sep 2022 14:55:57 +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 0195140695 for ; Mon, 26 Sep 2022 14:55:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21182; q=dns/txt; s=iport; t=1664196955; x=1665406555; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=A+RyAJxi7LUFT92eRkQwzVzQM4Vy1XAgnQ6cNZMTCG4=; b=YLUib0zPuL1X/ttxme6+xgcMCbsnmaGkXKHDAH145QthiR2HWjHW1VnK jXZvY5IMTGP/tE0tv4HvDba5RpAlwD8DC6+sONrBxrU32sQ30Wydt0hUo 1soXxrGV57UaJSsjAw51dh0XZXOvlNjr2GmAf7NJJSvYxNcngOK2bUXrx w=; X-IPAS-Result: =?us-ascii?q?A0AjAgC7oDFjmIkNJK1aHgEBCxIMQIFEC4EhMVJ/Alk6R?= =?us-ascii?q?YgaA4UviBYDiyuQO4EsgSUDVAsBAQENAQE7BwQBAYUFAoRsAiU0CQ4BAgQBA?= =?us-ascii?q?QEBAwIDAQEBAQEBAwEBBQEBAQIBBwQUAQEBAQEBAQEdGQUOECeFaA2GQgEBA?= =?us-ascii?q?QECARIbEwEBNwEECwIBCBEDAQIhBwchERQJCAIEDgUIGoJbAYIWVwMNIwMBD?= =?us-ascii?q?50pAYE/AoofeIE0gQGCCAEBBgQEgU4DDy+DAg0LgjgJgT2DMoNRgUaBPIIFh?= =?us-ascii?q?B8nHIFJRIEUAUOCZz6CIEIEgWAeBgcJg1iCLoQHlRUHNwNEHUEDC0I1GAMUA?= =?us-ascii?q?wUkBwMZDyMNDQQWBwwDAwUlAwICGwcCAgMCBhMFAgJNNggECAQrJA8FAgcvB?= =?us-ascii?q?QQvAh4EBQYRCAIWAgYEBAQEFQIQCAIIJhcHEzMZAQVZEAkhHA4aDQUGEwMgb?= =?us-ascii?q?wVEDygxaysdGwqBDCooFQMEBAMCBhMDAyICECoxFAQpExItBytzCQIDImcFA?= =?us-ascii?q?wMEKCwDCSAEHAcoJjwHWDoBBAMCECI9BgMJAwIkW4EvKAUDDRkmCAUjFx4EC?= =?us-ascii?q?DwCBQZXEwIKEgMTlxqBQYEwLi2BKQgOAQEifiUIHUcMOpF6FI4KoE1uCoNZi?= =?us-ascii?q?zuOd4YhFoN2jFCYPpcLjTyDZ5ERhQwCBAIEBQIOAQEGgU4TOoFbcBWDIglIG?= =?us-ascii?q?Q+OIBmDWYUUhUp1AgEIMAIGCwEBAwmKVgEB?= IronPort-PHdr: A9a23:cxXJtB8vzU2MZ/9uWCXoyV9kXcBvk7n3PwtA7J0hhvoOd6m45J3tM QTZ4ukll17GW4jXqpcmw+rbuqztQyoMtJCGtn1RfJlFTRRQj8IQkkQpC9KEDkuuKvnsYmQ6E c1OWUUj8Wu8NB1eGd31YBvZpXjhhQM= IronPort-Data: A9a23:F71WmK/5Onn+6dOBB1u+DrUDRX6TJUtcMsCJ2f8bNWPcYEJGY0x3m mQaUDuOOvzZamvzet1yO4y3/B8AvMDVmtA3HQNkpSBEQiMRo6IpJzg2wmQcns+2BpeeJK6yx 5xGMrEsFOhtEjmE4E3F3oHJ9RGQ74nQLlbHILOCa3sZqTNMEn9700oywbBh2+aEvPDga++zk YKqyyHgEAfNNw5cagr4PIra9XuDFNyr0N8plgRWicJj5TcypFFJZH4rHpxdGlOjKmVi8kFWc M6YpF2x1juxEx7AkbpJmJ6jGqEBaua60QRjFhO6VoD66iWuqBDe3Y4rPqM2N2FcigmDnop29 tlyq8zvFxkQa/ikdOQ1C3G0Egl3OalAvbTAO3X67YqYzlbNdD3nxPAG4EMeZNJDvL0pRzgVs 6VDd1jhbTjb7w6y6K+0TeVlmM05BMLqJ4gY/HpnyFk1CN53GcCfEvSQvYIwMDEYo59LAtSCf cMgNCtuaT/xUSxJYEkMMcdr9AuvriCvL2IHwL6PnoIs/2XLzAF3+L7gLMXSYN+SQdhQlEuC4 GXc8AzRDhwEHNCHxTnD9Wij7sfGmyrnX4YDUrel7Pdph0O7x2oPBRlQXly+ydG1j0+iQcMZK EsG/iszroA98UWqSp/2WBjQnZKflhcYX9wVGOog5UTRjKHV+A2eQGMDS1atdeDKqucmT2UAi HmCnu/jBGZojrGqVyLCqKmt+Gba1TcuEUcOYioNTA0g6tbloZ0ugh+ncjqFOPPv5jESMWytq w1mvBTSlJ1I1pdSiPvTEUTvxmPy+MeYF2bZ8y2NBgqYAhVFiJlJjmBCwXHf6ftGRGpyZgbc5 CFf8yRyARxnMH1gvCWJRONIF7az6rPZdjbdmlVoWZIm8lxBGkJPn6gOuVmSx28wba7onAMFh meI4Gu9A7cIZROXgVdfOd7ZNijT5fGI+S7Zfv7VdMFSRZN6aRWK+ipjDWbJgT6xyRN0z/pjY MfBGSpJMZr8Ifk6pNZRb7pNuYLHOghirY8ubcmhlk/+geb2iIC9GetVWLdxUgzJxPrU/FqKm zquH8CL0B5YGPbveTXa9JV7ELz5BSZTOHwCkOQOLrTrClM/QAkJUqaNqZt/INYNt/oOyY/1E oSVBxUwJKzX3yOXcG1nqxlLNdvSYHqIhS9hbH1xbAj4hBDOo++Htc8iSnf+RpF/nMQL8BK+Z 6BtlxmoahiXdgn6xg== IronPort-HdrOrdr: A9a23:FBCV9quBNlWHABTvlEiJ2gGo7skCyIMji2hC6mlwRA09TyXGra 6TdaUguiMc1gx8ZJh5o6H9BEGBKUmskaKdkrNhQotKPTOW9VdASbsC0WKM+UyZJ8STzJ8+6U 4kSdkCNDSSNyk3sS+Z2njCLz9I+rDum8rE5Za8854ud3ARV0gK1XYfNu/vKDwOeOAwP+teKH Pz3LsjmxOQPVAsKuirDHgMWObO4/fRkoj9XBIADxk7rCGTkDKB8tfBYlel9yZbdwkK7aYp8G DDnQC8zL6kqeuHxhjV0HKWx4hKmeHm1sBICKW3+4Yow3TX+0eVjbZaKv6/VQMO0aOSAZER4Z zxSiIbToROArXqDyWISFXWqk7dOX0VmgHfIBej8AreSIrCNXQH4w4rv/MATvMfgHBQ5e2UmZ g7r16xpt5ZCwjNkz/64MWNXxZ2llCsqX5niuILiWdDOLFuIIO5gLZvin+9Kq1wVR7S+cQiCq 1jHcvc7PFZfReTaG3YpHBmxJipUm4oFhmLT0AesojNugIm1kxR3g8d3ogSj30A/JUyR91N4P nFKL1hkPVLQtUNZaxwCe8dSY+8C3DLQxjLLGWOSG6XX50vKjbIsdr68b817OaldNgBy4Yzgo 3IVBdCuWs7ayvVeLqzNV1wg2TwqUmGLEHQI5tllutEU5XHNcjWDRE= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.93,346,1654560000"; d="scan'208,217";a="908499205" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Sep 2022 12:55:53 +0000 Received: from mail.cisco.com (xfe-rtp-001.cisco.com [64.101.210.231]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 28QCtrfH016706 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2022 12:55:53 GMT Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-rtp-001.cisco.com (64.101.210.231) 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:55:52 -0400 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-004.cisco.com (64.101.210.234) 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:55:52 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IXQHYlzVYOTdSHmg77kOZ5Rx9+o3l7x2lvpYO6vkJjtQ/NLRTptX5i0MiXeSVtWMDGM62JRgxGTwGjsFt8jJPmDK3F4QStQOdiZUViTnuvfqtrGnCptcJFmmGuTYrm7MTTF9Crd3u0ADv4b4/I72P78HdiLnleCG+0YEGHgd1/tuu1I/nqbABAVf971qcefvXKk+f5CnKs3ydjM1A2hjfIMVjV0jZ+4kO8x0IBlSNPEPZGm6BcyyzCPNwjdH0WjPPGGjLunOWopj6GmP366/WRsppHmHEHdFe7iobLz/qAMnpzsf+3bKT6UJqdQ3wVvyt0GtNuajRBvtUOwkiZ9qTQ== 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=rOTWVdgvfAiTbfKqOKF314ExUan0zWo+dUFGlgTlYoY=; b=LJ6TlGlsy70j1WLq3jRMaP0pbOFoE+tTvYhFxHk8i/NZZ8+TQT246QQ1EJ4ffrlA+yDcwC05Bo9y8LmLWOHwweQBA6B94fQmPByCAKZJw6QtbHYgyx8xq0lw1c2zdJFCbR4Y2KkiXxeGzWMfKc5qhHEETD85sNgYQabXFm0U8MDr0dZy9MeKmEIvTuWMYuJJ+6kbjrjgV2zytnazvYKb758u4ZLjQfonfE48VbFBN5xEKziKhqf/VC92GwpIXEgaO6ko2NJGpFQtrsOey/6gBDfnLRn8Kvq62hLHIXJ2mAMsPv5nv7Dip4osTKAy3WevTO43qKWCOc2dPVePKyDzPg== 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=rOTWVdgvfAiTbfKqOKF314ExUan0zWo+dUFGlgTlYoY=; b=r91hY0hP1onRMt595DM12A6xSzaszrY1jNsM4zqXGZODfu2/fMRoFg9v2cNslL4zenZzRLLllKEuzPPv+36FArqww4X4YEMBS1SaeVBcY0gDZJjPEsq43Fi6Yqqi6H1fCW+fBqMG270eI04NcpYA8+F3yoImktQ24wdg504f5qI= Received: from SJ0PR11MB4846.namprd11.prod.outlook.com (2603:10b6:a03:2d8::24) by SJ1PR11MB6204.namprd11.prod.outlook.com (2603:10b6:a03:459::19) 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 12:55:51 +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 12:55:51 +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/TnQXrtK3pfBK4gAGoheSAAA73AIABtqxUgAAKNICAAAVZ9oAAEfuAgASvCUg= Date: Mon, 26 Sep 2022 12:55:51 +0000 Message-ID: References: <20220922120052.710c2cd1@sovereign> <20220923144727.155be566@sovereign> <20220923161057.0205e703@sovereign> In-Reply-To: <20220923161057.0205e703@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_|SJ1PR11MB6204:EE_ x-ms-office365-filtering-correlation-id: c9c9dd30-2dcb-4801-b242-08da9fbe7122 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1paEJDfQEzpTHjNJrqTc+pYKYqpsDK19x/yBTMiWoRgD6rhbSmy9+FJ/SWxW5yzujRBuDwhZBN3X9lao+Hy8uvT5wGd29wv1gjHR1Tfb9zG9tva7QUtZHeuEuncgMw1aOl6Dnd/Byna6fc6gs7gqJkL7ZZY85B8H6EXF0FJuo90WyUqcFoq9ysEtYMdYh1857EvmqN9RNvRd1gfkLbOVQHhWH+/fozti6vdUPoBlswHWU3gwc1ui7T1k3lliZFgsfDc19PkNW97i+EgbIeMSJ8W+gwz81s6NkzepUkjHhFWi69C8nFWw3QAaQtI0jk75wiAjuq4Z1HKjAvLbke8QS4MVshUfo2RaFLHV1X+EfzmrJase+DXQGZAIBd0qdv3jlyQptdaF9BIA86/7zOldgLoZ7E1t6y+K2CmWpXErXRb6D2HB2sKyRcxEdEuL/UhZdxr4PIhbHa9yDw4kYA5cvH2TNXTV+W04zGzdnrDaHsMT/ssILR+LbtqX4wvXKZbMCMfXxYyGqYcBMrR7bmlzzRcIK6p5xy0HXe+VHtBKIE5/+/UB5kwU5miDT4DD3dBg/ZvtgUcXnk1z1SLGGTafPTXf7lsHevB7Wr45R1+N/2QmLUhM/E3TdatrwnsBR/WQVK71uvOUxlMPCTnUIKNsB+FhCoGPbW4GBX7/NnfyJtFtHcBH7CLV43nkp2uKaJg9b5zM7wwPYrv1bcp8ZSKbMgj7akt/Rf+9llopCUTQjZdBkp51ZNFGGChhX14WseCldaA1dguIQeb3y3ZI4rg4T6ZDVn5Z9dvqAcuMtgyApyayuJIJ/f7vXMJSenk82YANuWa0/I9gvtVJ5Xn/r+70vg== 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)(346002)(39860400002)(136003)(376002)(366004)(451199015)(86362001)(166002)(38100700002)(33656002)(122000001)(38070700005)(2906002)(186003)(26005)(5660300002)(55016003)(966005)(55236004)(6506007)(53546011)(41300700001)(478600001)(7696005)(71200400001)(9686003)(83380400001)(316002)(6916009)(54906003)(91956017)(64756008)(8676002)(4326008)(76116006)(52536014)(66446008)(8936002)(66946007)(66476007)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?7+sxKm6QeHSI9PjR/HLHict+Vke+bdm+m1hFDhYgg3rwy6cM7dMk4A8J?= =?Windows-1252?Q?MkfBo25fwAL52ZZO9wxI0phLCKztcW4z48az+N2r/j96+f6T6+rixuAW?= =?Windows-1252?Q?6sCEidxNT77qf3tB2ExaogD/JVa2kbIxb8gUYdIvn57TpTE75zxWwInh?= =?Windows-1252?Q?21V5m16yIZb4h37YFPmDVIdHf81O7gpSqGvBtnNVRs5HI/8uEZ7M6pK6?= =?Windows-1252?Q?sC0DrdmfwsjOZv6TTCGb/uciGALHWNsoFvThx4S27wUm7jupoCgJ6xDv?= =?Windows-1252?Q?123bkLVZRKMAIEfJ5vfj3bgCzNA7ha4qPhsdUDGV7pFd7iLchseBzfv8?= =?Windows-1252?Q?3zy0pzVM1MSnIGc0hVn4FpsP9myCpthjTIcf80p8w172yyOlkpfHayWx?= =?Windows-1252?Q?Mp/vU2cn5bZZReRwGIf/VknLYLmE1Gilv1KnUdLUDWE7+MFjtLQpAx8G?= =?Windows-1252?Q?+/r0yyI6TnGpajNZpyx6KXFmG8AiIGEvjK8q0dk8q52lIurFC9PFNbNq?= =?Windows-1252?Q?Oq/Q4pRa1iNhI5VZM7WYhsz/llIu+OHcaWkwXmTW/GlUN/gPVc424ngt?= =?Windows-1252?Q?DXfy9cZT6iVZYrg8I8GpKEIG0lcuJ7VcAlv3M0qz6Fh2o3AtjFDcf78A?= =?Windows-1252?Q?VjBdoFhQiXBkv7itHjsSZn19Us/pxU+gMZgcHC+KQTTKw69/GBoYhYsj?= =?Windows-1252?Q?Fn0qlOxNClgCkJmLVrYkOqThUoloXMuFU5NImsMF+uRzp2ntuLwPhZvy?= =?Windows-1252?Q?h+wiwZcfArT/k1NaAjICJoKTGYjdyWtI0H6SiYPjxbqipQ0NZ4ayCMBr?= =?Windows-1252?Q?S9nhy2IfHc87YhPLgFqnt5gMsdKUMtT1EWtpkdzeEL1WX7ffPnvvI1iy?= =?Windows-1252?Q?Kle4o2GrIqS/W5hhlSqAGrDOAHrrMI55IPuoRUHeVev4ALlI3vZTzNbV?= =?Windows-1252?Q?3BhdLgckUmzq2Jm+yn3aiJ2LfkN2O+CE0gDUDoY+5CGmKVqaZqwOMCwb?= =?Windows-1252?Q?Gc1EnmHNo3qRNveicTnfXwbYCSanSsS9TCyASHMkhQ7GVZJRWhHCUOQz?= =?Windows-1252?Q?67gkLsmZYx4TUzeFbL+muvR8N+2VxpOEncQNQxnuIhcbaws18RDuAGIi?= =?Windows-1252?Q?32GgYJcd3vwks/PoA3TRBmEwphPnpkmgc925hh7v+p4/bAs02qnOVI7G?= =?Windows-1252?Q?NnEq6TGumjymHMFikd0UHy2yW8tPAO/ySbCiiNvL+h1m8UbmynJgX3NQ?= =?Windows-1252?Q?XyKh4LYKGY0D2L57hrh0FsA9aMuP0rdx0mm5ax182YFVKOCGEoGsMLGD?= =?Windows-1252?Q?2qyKffw2qA/DuHBuqsPrBPZV4m/M9+uNfHzLkW9piLFGp61fCI5KCqaB?= =?Windows-1252?Q?aSX48uEX946a3pPCxQFZd5ADMuem/7BbS/deYL7MKHWmz38L4PMrbvH3?= =?Windows-1252?Q?AIZvHs8WBbexFS1i0esvbj5z2eKHP8dDwOnboadHCIW9m9Zz2bkqw8Re?= =?Windows-1252?Q?vrDIXw7HXpdwLIAVwtF/JNDjExIDpECA3GqBrMdycXWbKUDw/y9BhUk5?= =?Windows-1252?Q?asHib9RUbvRFQ9q1j6N/TyW6gD4XNMsf3lgdW6Akqqnnu1J1+CK+QB0X?= =?Windows-1252?Q?9DtkmLPL782ryqfPzWYw8CfW0JQ9WICiCs2aZSn/A2KxXPATQKaetDjn?= =?Windows-1252?Q?rti6dNK3b6Pqdytf1gPrIEbMWErSfzEfnCqPDg6nRS7IiSx8xz6Z2g?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_SJ0PR11MB48463D47B2E5FADE0405C120DD529SJ0PR11MB4846namp_" 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: c9c9dd30-2dcb-4801-b242-08da9fbe7122 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2022 12:55:51.6892 (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: dbfQ5Deeq5SNlnhCIUWrLHkKjzCT6DizDJnWh26+DxXL43PFrDo9WebFhpsasCLK5h5AlBOy2l5Y1K7dceNilw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ1PR11MB6204 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 64.101.210.231, xfe-rtp-001.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_SJ0PR11MB48463D47B2E5FADE0405C120DD529SJ0PR11MB4846namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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_SJ0PR11MB48463D47B2E5FADE0405C120DD529SJ0PR11MB4846namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thanks @Dmitry Kozlyuk for your suggestions

&nbs= p;

I will tr= y the following for DPDK pool creation

&nbs= p;

My logic = of calculating MBUF=92s remains same

&nbs= p;

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

&nbs= p;

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;

 =                     &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");

&nbs= p;

  &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");

&nbs= p;

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

  &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;             }

&nbs= p;

So I will= do the same

&nbs= p;

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

&nbs= p;

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

&nbs= p;

We have t= otal 3 types pool creation

&nbs= p;

/*

 * 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

 */<= o:p>

&nbs= p;

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<= /span>

&nbs= p;

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

&nbs= p;

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

 

Thanks

Umakiran

&nbs= p;

&nbs= p;

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_SJ0PR11MB48463D47B2E5FADE0405C120DD529SJ0PR11MB4846namp_--