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 24D72A0543; Thu, 22 Sep 2022 10:08:20 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 00C1E40156; Thu, 22 Sep 2022 10:08:20 +0200 (CEST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by mails.dpdk.org (Postfix) with ESMTP id 1F690400D7 for ; Thu, 22 Sep 2022 10:08:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40763; q=dns/txt; s=iport; t=1663834098; x=1665043698; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PdjgcwSkGRzp2VwbRfr7/xdyEZwTrNSHfy0AYVEdwhY=; b=gBo9O43RNEPSAcYJZXJHGKXHjkc0lk/D0ZNxrHDorO9791VkUhpRXRqf zuDDsMC0UsgvPuzsM+C+HRR83S0JzZam65uiGe0acHVsEn8FjeiUF+/RM Hq3XMyYa9U2DQAQ3MZA7MQIWRpt5vf5OkHqXO7dcdoxmQHNPktiTN+Vm/ w=; X-IPAS-Result: =?us-ascii?q?A0AyAgBgFixjmIMNJK1agQmBT4EhMVJ/Alk6RYgaA4Uvh?= =?us-ascii?q?XGCJQOBE5pSgSwUgREDVAsBAQENAQFCBAEBhQUChGwCJTQJDgECBAEBAQEDA?= =?us-ascii?q?gMBAQEBAQEDAQEFAQEBAgEHBBQBAQEBAQEBAR0ZBQ4QJ4VoDYZCAQEBAQMMB?= =?us-ascii?q?hUZAQE4DwIBCBEDAQIhAQ0yHQgCBAESCBqCWwGCFlcDMAMBni0BgT8Cih94g?= =?us-ascii?q?QEzgQGCCAEBBgQEhREYgjgJgT2DMYUXh18nHIFJRIEVQ4IwNz6EDwESASMeg?= =?us-ascii?q?26CLpkdBzcDRB1BAwt2AxUDFAMFJAcDGQ8jDQ0EFgcMAwMFJQMCAhsHAgIDA?= =?us-ascii?q?gYTBQICFzY4CAQIBCskDwUCBy8FBC8CHgQFBhEIAhYCBgQEBAQVAhAIAggmF?= =?us-ascii?q?wcTMxkBBVkQCSEWBg4aDQUGEwMgSSYFRA8oMWsiCR0bCoEMKgkfFQMEBAMCB?= =?us-ascii?q?hMDAyICECoxFAQpExItBytzCQIDImcFAwMEKCwDCSAEHAcoJjwHWBIoAQQDA?= =?us-ascii?q?xAiPQYDCQMCJFuBAywoBQMNGSYIBSMXHgQIPAIFBlcTAgoSA5l4ghSBZTUFk?= =?us-ascii?q?0iNP0afPYE1CoNWiVmWdxaDdoxQmD6XCiChZ4U4AgQCBAUCDgEBBoFhOmtwc?= =?us-ascii?q?BU7gmdRGQ+OLA0Jg1CKXnU7AgYLAQEDCYpZAQE?= IronPort-PHdr: A9a23:PRnCRxCVoNpmXMyshNBCUyQVaBdPi9zP1kY95pkmjudIdaKut9TnM VfE7PpgxFnOQc3A6v1ChuaX1sKoWWEJ7Zub9nxXdptKWkwJjMwMlFkmB8iIQUTwMP/taXk8G 8JPHF9o9n22Kw5bAsH7MlbTuXa1qzUVH0aXCA== IronPort-Data: A9a23:A2+hXaPktZQO/OjvrR2Il8FynXyQoLVcMsEvi/4bfWQNrUp3gTFWm msZX2mCPanbZ2GgLdwkOo6+/U1QvpKByNJlT3M5pCpnJ55oRWUpJjg4wmPYZX76whjrFRo/h ykmQoCcaphyFBcwnz/1WlTbhSEUOZqgG/ytU4YoBggrHVU+EHZ700o68wIEqtcAbeaRUlvlV eza+6UzCHf9s9KjGjtJg04rgEoHUMXa4Fv0jHRnDRx4lAO2e00uMX4qDfrZw00U7WVjNrXSq +7rlNlV945ClvsnIovNfr3TKiXmTlNOVOSDoiI+ZkSsvvRNjncd1KAxOt9NU2ZesBKpmcJq0 81CpLXlHG/FPoWU8AgcexBcFyc7Nqpc9fqeZ3O+qseUiUbBdhMAwd03UxpwZtNeo70xWDoXn RAbAGhlghSrmu2xzLulQ/NEjcU4J86tN4Qa0p1l5WCHVKh8GM6ZHM0m4/dbwjILqf1sFsqDR NsnKgAoVgqcekdmbwJ/5JUWxbf02SaXnydjgEmJqLI37m77ygFtz7/3M8LRZ9mASN8TmVyXz krK8nrRDgkWN5qY0zXt2nuqj/PImTK9Up8IHb6/6NZrhkGewioYDxh+aLegifC9jkj7UNVFJ glNvCEvtqM1skesS7ERQiFUvlbfkRgaUdR1Qtcb4Tqq6qzG+B2BCXktG2sphMMdiOc6Qjkj1 1msltzvBCByvLD9dZ573urKxd9VEXVIRVLudRPoXiNeuIC6/99bYgbnC4c9TvHk17UZDBmqm 1i3QD4Ca6L/ZCLh/4y/+V3B695HjseUFldujuk7s57M0++UTIehY4rt4l/B4LMZao2YVVKG+ nMDnqByDdzi77nQxERho81UQ9lFAspp1hWH2DaD+LF6rVyQF4aLJ9w43d2HDB4B3jw4UTHoe lTPngha+YVeOnCnBYcuPdzqVJR3lfOxRYq8PhwxUjaoSsUhHONg1Hw+DXN8I0ix+KTRufhlY MzCIZrE4YgyUPw6nFJauNvxIZdylnxhmgs/tLjwzg+s1vKFdWWJRLIeWGZinchnhJ5oVD79q o4FX+PTkk03eLSnPkH/r9VJRXhUdidTOHwDg5ENHgJ1ClA4SDhJ5j646e5JRrGJaIwOybiQr yDkARUBoLc97FWeQTi3hrlYQOuHdf5CQbgTZETA4X7AN6AfXLuS IronPort-HdrOrdr: A9a23:nFU0LqPt5GglVsBcT0b155DYdb4zR+YMi2TDiHoedfUFSKOlfp 6V8MjzjSWE9Qr5K0tQ5exoWZPwC080kKQV3WB/B8baYOCLghrLEGgm1/qZ/9SCIVyyygc+79 YZT0EWMrSZZjIW7beY3OD7Kada/DDtytHNuQ6q9QYKcegcUdAG0+4WMHf/LmRGAC19QbYpHp uV4cRK4xC6f24MU8i9Dn4ZG8DeutzijvvdEFI7Li9izDPLoSKj6bb8HRTd9AwZSSlzzbAr9n WAuxDl55+kr+qwxnbnpiDuBtVt6ZXcI+l4dYyxY/suW3bRY8GTFcZcsoi5zXEISSeUmRMXeZ f30lMd1o9ImgzslymO0GXQMk/boXETA7uI8y7AvZMlyvaJAg7SQvAx9L5xY1/X7VEts8p717 8O12WFt4BPBReFhyjl4cPUPisa33ZcjEBS5tL7tUYvJ7c2eftUt8gS7UlVGJAPEGbz750mCv BnCIXZ6OxNeV2XYnjFti03qebcFUgbD1ODWAwPq8aV2z9ZkDRwyFYZ3tUWmjMF+IgmQ5dJ6u zYOuBjla1ITMURcaVhbd1xCfefGyjIW1bBIWiSKVPoGOUOPG/MsYf+5PEv6OSjaPUzve8PcV T6ISZlXEIJCjDT4Je1re12Gzj2MRaAYQg= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.93,335,1654560000"; d="scan'208,217";a="961621627" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Sep 2022 08:08:14 +0000 Received: from mail.cisco.com (xfe-aln-002.cisco.com [173.37.135.122]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 28M88EJN021233 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2022 08:08:14 GMT Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9; Thu, 22 Sep 2022 03:08:13 -0500 Received: from NAM02-SN1-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; Thu, 22 Sep 2022 04:08:13 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oLjeeckvmENXChKk+vIz/OtGz3g7PHYBC5oJJcj/ej138PE9lf7UwzjtJpNLQ5hQdKZ0jrhS5EmFUQgjtDjc5HrKdI/GyqR2d+wNJXk4pQcBDKEvDrXrHyzOJNEvvN1R+5vSy+sUvIMjJiGyoZ2g4qcYKrZPCoWo2czNnBsQ5CziI+MIV7zaLPi4PanbWw+ncX4k3iUA/+kdjq8KKvH7V4KI5686qArzCu/FCBHmQ3X+5OQrE8PlaFUWmqohyu0hBbpfpnqbjc23eGf9n1M94FN6xSYFWp+v7rEQ5xJZylGy0EpwC1hvUZgVIxtXAYeRPz2SdQKvbjXA/YDvbDoTTw== 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=RJZIrWbN2DoeVxXm+ulr/fmLORmQ9wneRuKQeoo7N4s=; b=eYBkR1CnALPYj8Ff8ECRV+lnBNrTbl1ZRqS1LxnpdS5Jf69pXKpxAsvCElVEUBW0deqxLhf5UgcH/zxx1PHSqHehEKUN7XVQvEKtK5MaLYzoadKi4Hh0Won2iUW7TH7DV/1ZWVVvtZvQ8F2hya8mopVG1D9IyLl6SMiNE88JvWgsrAODRAN8fqohBOjJSSKUMrADnWsj8LMI97Si+qoNoPhij6/poPGdX7oAMo7p7aRgXtIb3eWZpT/8UorvRbqAzPudkTfq+QZDQVo4x0hrcrkKgEdvXJ/ZkCkcjH2zLpGX4vIRpBbNfEWuN7AGDmTFGXRIFkd98W9CadO9FQjFvQ== 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=RJZIrWbN2DoeVxXm+ulr/fmLORmQ9wneRuKQeoo7N4s=; b=T6+wQqCwkSquI4P15c33hADhv+5R9JpXyrshueHwmvIYYv5NQQnqGNnMQrZUBL6+mEULQ42Mt7IDTPWReVyTwWukEoSo8yLqC/Ua1G+xLyahgPql8b2J5XPUoFEBLZx4pXJoiLeNELzw9rhLJwgMLgynjqtMuRZEq1q4U1OnrO0= Received: from SJ0PR11MB4846.namprd11.prod.outlook.com (2603:10b6:a03:2d8::24) by MN0PR11MB6011.namprd11.prod.outlook.com (2603:10b6:208:372::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.14; Thu, 22 Sep 2022 08:08:10 +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.017; Thu, 22 Sep 2022 08:08:10 +0000 From: "Umakiran Godavarthi (ugodavar)" To: "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/TnQXrtK3pfBK4gAGoheQ= Date: Thu, 22 Sep 2022 08:08:10 +0000 Message-ID: References: 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_|MN0PR11MB6011:EE_ x-ms-office365-filtering-correlation-id: 2f9858b3-25c8-4039-b066-08da9c719739 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JSKtyOni1Stjv/4zW200280NvCx+/JypMJpQs4nB4eWj7gh2lB3s6js68TVogx1OblXs5HOuFc+66NvpcpqyYs3tsvQebfIsdg6SvyPs/X9pLhGFwcRUHtfag0tmcxzzUHOaypz7fEbDaH4Kd+ZHhU4E9V3+mBngtMlUiVVkLCNBnvP8rvdgHwKkZlSOXnlmEuwn5YX/amjcQyLKmUNhtqPBp2ZZt4LVsmqKG+NzivPViVXM/a6kuixMQLqvf1cYfwcuGkhsIZY9lMRgW9VbYFdU24pkZun4ZtqHetD9Mh0L4V3fSlp6npr4NPdENvwgHNQ/mcK3oyWRSVDoFgoB5dbw+YnfUW4j/YzDyNNoxmxUnafedT7QlP7fF1wjmktGhed4Bg0QjOeSH6S2SdHfT6Hp81nEjxTd02KQnXao9MmMYWkl4pxSV0fpszVnExabCX66ECQ0Y7JcFzHxWSfo5ouRI25EknUh7w36qWV4OZfL/00zgJpVqmmiCGFE73zIVgIKbNRFet5KgFgeABFzDtcVYAS2EKK2/xFzueCbvY94Zk1yvRmvrG4uWFpgv0JCTD5nEFvfLucYthxDismWay4YLo+7tb8qBjMafar20nQtwInRmOTxZCPmjRzucEsz2j/oDno9kjXks1JqXs35+PlZAoVhseCqDjpbZtw5MMt6FxiqKbfNDeyiLq4i6Htku/YvAyUhcw0yPBukqOGt/7eCHCY5Owbu9CQ3IP/il5SaYtbxxUnd1dZiolvlBw2XRoXLLrTK93cFH2nvcS1XEQ== 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)(136003)(366004)(396003)(376002)(346002)(39860400002)(451199015)(38070700005)(38100700002)(110136005)(83380400001)(7696005)(86362001)(2906002)(33656002)(26005)(316002)(478600001)(9686003)(41300700001)(55016003)(53546011)(55236004)(186003)(6506007)(71200400001)(64756008)(91956017)(66946007)(76116006)(66446008)(52536014)(5660300002)(8936002)(8676002)(122000001)(66476007)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?dkbCZJyHhti0mZtLyL+gIf5RUAx0SSxCA/bjayWOD2vYxi5d6RDpS3cZ?= =?Windows-1252?Q?HpIDyx59LfazYOpyDONttYut//2YdmhnbbzWy4UOFSlPQVjlR/Jhumv6?= =?Windows-1252?Q?+D6+GD5sKhhqmALKuZ2iq7PbCrEbbeTzmUGjLVsorDoU/T8OY1jHQbpz?= =?Windows-1252?Q?4ObukhKZ+IQWYICJ/U5o5eFMrhOqfdtXarwKzQdTg6uS2/OY3wxlFQ7m?= =?Windows-1252?Q?KfFoPUvOeLcR2W2ZQzkc5McSIWI1yEZ92DTCOFB7/M2YLDySecDXJ2W/?= =?Windows-1252?Q?lbfbqDepHZ0b6L6YncJmaIvmNddvbTodgDZjqewRHdS8cWp2J8eECCwf?= =?Windows-1252?Q?cw6ZRTUGrqZUhNhLWjVTXvXmDQNv+xYxEIjDkM7icRlbes7vfkJ/y81k?= =?Windows-1252?Q?2m4AXDa2O/Xl8iIIB2Iszi+9emUpm0YleeTCzoR3674PbjPysPkgZiK7?= =?Windows-1252?Q?NHX5VUYC9g8GTnT+IdgQMXDjKHWEbAZ8nkJKAVy85zRVLH/tOYx1QpMa?= =?Windows-1252?Q?Xlw+/9gPEiDR1rckgXmQnzshwqef2L8NIrVuEp7vVf6ia/T6DXsfESuP?= =?Windows-1252?Q?CgXs0fxdbRUFgTggvo2MecIu17nlI8qy/WlEL/SpXUzfOfhpQBc/genp?= =?Windows-1252?Q?Nkwj2M66z1aA3UxGHt+O7cjK5raO3wgxbNiCYxIz+3Uwb9ZpYOXi8Imt?= =?Windows-1252?Q?VJ2LE6syeQsnztg+3HjWu5kwzyk2YXcY8MNUdsfLzXs6/3GatzsK4HZH?= =?Windows-1252?Q?9khN0uVXxygjBojkXcRUE9IxSvBJKFThGDtKC49BT7NqZoo2XvXTvFSw?= =?Windows-1252?Q?nM3hGg/eQqVlLesvhhW/MDUmJGCNFZh7EiurjJlOsPeeRhO9vnu7mYBc?= =?Windows-1252?Q?EQUZj1ou4FDRlUbMcM7Oabm0wmsXVUn2iCnvs636ycHfsp8lYfbZOWkl?= =?Windows-1252?Q?uuqLtxrTRAViMJLnH+wpfGNpDSEjg4QFLyJbeY2ceE89XoVaHhidb2lV?= =?Windows-1252?Q?agR3gkuMj3NK9yIF7BXH3cs70MJ/RF0mlbmDgfyx6LcHgnoHw471lJpN?= =?Windows-1252?Q?5Tqeq6xoSXhjBQWKUuSFGac1USfrdxfc7n7INh/DpL78Ld8EKnR0FNXr?= =?Windows-1252?Q?uxm3HeGkyKudNCiUVw03Q2muZd6mme7vOV1T53VZJVFiMAN043bMbwNs?= =?Windows-1252?Q?WA5dT2XZ3ZOPH0SoYzMkBe0b2O1TV9YJG+MQukEae6OloV+HVuOE8V2K?= =?Windows-1252?Q?kQUCQP09jFULZ+NjJr9sjESqM5Tpdv3b2DDzBmD8pg0PSE5o3wQnIC5p?= =?Windows-1252?Q?0k9hE7yXQZZsNm5A78hoZz/j4acPfjqcgbiX/NShXqA8S36Z8rQhJubS?= =?Windows-1252?Q?nryAH7j6X+l4CqhcGebT2DnX0/91ucDngCIG18VGmrtrkLuZ7fU+rIWZ?= =?Windows-1252?Q?v194KkovqnaOXFby0ByK/61+t5bHMVB9BbpP1MHqJkKaS8jHdf8u3IC8?= =?Windows-1252?Q?pZvlGQB2Mz4cfPrNBKMMPsR+LySlGA6AQ49295lUtOhomhwSjIf2AhCI?= =?Windows-1252?Q?MaMFuVIZ9BnGT//WFRg+pNlQsM/ZiEyQdnm3W5BoC2/EAKpbt+Unav3o?= =?Windows-1252?Q?hsxKveLGjyq/KaxWuExeTy7Oe5OA3Sgzs9FjMwtgdFVG3tKWJhABss6l?= =?Windows-1252?Q?AZeTCtNBYPup6TaHbwjMQ4eGpOMRcFZ0oH9Lk3uQprues3yTENYtQA?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_SJ0PR11MB484677FEEE61AD8CF101875CDD4E9SJ0PR11MB4846namp_" 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: 2f9858b3-25c8-4039-b066-08da9c719739 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2022 08:08:10.8255 (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: LO5I96TD7EhauWAEIigZqaOBbzNzxL2DYuJkJztnWE0oMlHcIRaW5pTd+XXaJlbwQpqp77WHphbKvZVCAo2uvQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB6011 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.135.122, xfe-aln-002.cisco.com X-Outbound-Node: alln-core-1.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_SJ0PR11MB484677FEEE61AD8CF101875CDD4E9SJ0PR11MB4846namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Stephen/Anatoly Burakov Please help us in below RTE EAL CRASH reason is it we are not getting segme= nts for POOL creation or a bug in DPDK 19.11.5 ? We are blocked !!!! Thanks Umakiran From: Umakiran Godavarthi (ugodavar) Date: Wednesday, 21 September 2022 at 12:20 PM To: anatoly.burakov@intel.com , dev@dpdk.org Subject: Re: DPDK 19.11.5 Legacy Memory Design Query Hi Team, Have sent a message to DPDK alias. Can you please have a look and share your thoughts on this ? Please reply on legacy memory design and thoughts on the crash reason ? #6 sigcrash (signo=3D11, info=3D0x7fff1c1867f0, ctx=3D0x7= fff1c1866c0) #7 #8 malloc_elem_can_hold () from ./usr/lib64/dpdk-19/librte_eal.so.20.0 #9 find_suitable_element () from ./usr/lib64/dpdk-19/librte_eal.so.20.= 0 #10 malloc_heap_alloc () from ./usr/lib64/dpdk-19/librte_eal.so.20.0 #11 rte_malloc_socket () from ./usr/lib64/dpdk-19/librte_eal.so.20.0 #12 rte_mempool_create_empty () from ./usr/lib64/dpdk-19/librte_mempoo= l.so.20.0 #13 rte_pktmbuf_pool_create_by_ops () from ./usr/lib64/dpdk-19/librte_= mbuf.so.20.0 #14 rte_pktmbuf_pool_create () from ./usr/lib64/dpdk-19/librte_mbuf.so= .20.0 #15 dpdk_create_mbuf_pool (mem_chunk_tbl=3D0x555d556de8e0 , num_mbufs= =3D46080, frame_len=3D2048, name=3D0x7fff1c1873c0 "DPDK_POOL_0") Is there a bug in DPDK 19.11.5 it crashes when it searches for pages for PO= OL creation Please let us know this is second email Thanks Umakiran From: Umakiran Godavarthi (ugodavar) Date: Wednesday, 14 September 2022 at 1:00 PM To: anatoly.burakov@intel.com , dev@dpdk.org Subject: DPDK 19.11.5 Legacy Memory Design Query Hi Anatoly/DPDK-Developers I am working on DPDK 19.11.5 Legacy Memory design and have a query about ho= w to boot up in Legacy memory mode. 1. Linux kernel boots up with huge pages (=91N=92) and free huge pages (=91N= =92) initially 1. We calculate huge pages we need for data path (Driver need buffers fo= r all queues) by sorting the memory fragments 2MB huge pages fragments and = find we need =91X=92 pages , so we go to kernel and set SYSFS attribute nr_= hugepages (/proc/sys/vm/nr_hugepages) to X pages. We also store the sorte= d physical memory fragments as POOL_0, POOL_1, POOL_2=85.etc. (Just for poo= l count purpose enough for all ports and queues to initialize) For example, if host has memory pattern huge pages like this for total 500 = we get in step 1 kernel reservation. 250, 90, 80, 70 , 10 -> Sum is 500 (N pages) We need only 350 pages (350 based on no of ports, queues dpdk application n= eeds) So we need 250, 90, 10. So total 3 pools POOL_0 -> 250 pages, POOL_1 -> 90, POOL_2 -> 10 pages 1. We boot up DPDK by RTE_EAL_INIT 1. Then we go to DPDK Memory segment list walkthrough and for each FBARR= AY , we find the used pages by DPDK and unmap the remaining pages by below = 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 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 list = (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 free= 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->p= age_sz); munmap(addr, RTE_PTR_DIFF(RTE_PTR_ADD(msl->base= _va, msl->len), addr)); } } 1. With NR_PAGES As =91X=92 and FREE_PAGES as 0, we create MBUF pools us= ing RTE API and we face crash (We take care =91X=94 pages has multi pools b= ased on memory fragmentation given to the primary process, so pool by pool = we have confidence that DPDK should find physical memory segment contiguous= and allocate successfully) struct rte_mempool *pool; pool =3D rte_pktmbuf_pool_create(name, num_mbufs, RTE_MIN(num_mbufs/4, MBUF_CACHE_SIZE), MBUF_PRIV_SIZE, frame_len + RTE_PKTMBUF_HEADROOM, rte_socket_id() 1. Sometimes randomly we face a crash during pool create in Step 5 for e= ach POOL stored in Step 2 process for all ports and queues initialize later= on DPDK EAL core comes with BT like this #6 sigcrash (signo=3D11, info=3D0x7fff1c1867f0, ctx=3D0x7= fff1c1866c0) #7 #8 malloc_elem_can_hold () from ./usr/lib64/dpdk-19/librte_eal.so.20.0 #9 find_suitable_element () from ./usr/lib64/dpdk-19/librte_eal.so.20.= 0 #10 malloc_heap_alloc () from ./usr/lib64/dpdk-19/librte_eal.so.20.0 #11 rte_malloc_socket () from ./usr/lib64/dpdk-19/librte_eal.so.20.0 #12 rte_mempool_create_empty () from ./usr/lib64/dpdk-19/librte_mempoo= l.so.20.0 #13 rte_pktmbuf_pool_create_by_ops () from ./usr/lib64/dpdk-19/librte_= mbuf.so.20.0 #14 rte_pktmbuf_pool_create () from ./usr/lib64/dpdk-19/librte_mbuf.so= .20.0 #15 dpdk_create_mbuf_pool (mem_chunk_tbl=3D0x555d556de8e0 , num_mbufs= =3D46080, frame_len=3D2048, name=3D0x7fff1c1873c0 "DPDK_POOL_0") We see find suitable element does not able to find a suitab= le element in DPDK memory segment lists it searches for HEAP ALLOC and retu= rns NULL and NULL dereference crashes boot up process Please let me know any comments on boot up process for 1-6 and any reason b= ehind the crash ? We are suspecting Step 4 where FBARRAY unused pages freeing at last should = free the least contiguous memory segments right ? (munmap after finding 2 f= ree pages , entire length we unmap in step 4 to free virtual memory) Please let me know thoughts on FBARRAY design, is it expected to map the mo= st contiguous=85..least contiguous in a virtual address space right ? So our most contiguous segments in Step 2 is safe even after Step 3, Step 4= we believe. Please correct my understanding if anything wrong. Thanks Umakiran --_000_SJ0PR11MB484677FEEE61AD8CF101875CDD4E9SJ0PR11MB4846namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Stephen/Anatoly Burakov

 

Please help us in below RTE EAL CRASH reason is it we are not getti= ng segments for POOL creation or a bug in DPDK 19.11.5 ?<= /p>

 

We are blocked !!!!

 

Thanks

Umakiran

 

From: Umakiran Godavarthi= (ugodavar) <ugodavar@cisco.com>
Date: Wednesday, 21 September 2022 at 12:20 PM
To: anatoly.burakov@intel.com <anatoly.burakov@intel.com>, dev= @dpdk.org <dev@dpdk.org>
Subject: Re: DPDK 19.11.5 Legacy Memory Design Query

Hi Team,

Have sent a message to DPDK alias. = Can you please have a look and share

your thoughts on this ?=

 

Please reply on legacy memory desig= n and thoughts on the crash reason ?

 

 

      = ;           <= span style=3D"font-size:10.5pt;font-family:"Helvetica Neue Light"= ;color:#0F0F0F">#6  sigcrash (s= igno=3D11, info=3D0x7fff1c1867f0, ctx=3D0x7fff1c1866c0)

    #7 <= o:p>

    #8  malloc_elem_can_hold () from ./usr/lib64/dp= dk-19/librte_eal.so.20.0

   &nbs= p;#9  find_suitable_element () from ./usr/lib64/dpdk-19/librte_ea= l.so.20.0

   &nbs= p;#10  malloc_heap_alloc () from ./usr/lib64/dpdk-19/librte_eal.s= o.20.0

    #11  r= te_malloc_socket () from ./usr/lib64/dpdk-19/librte_eal.so.20.0=

    #12  r= te_mempool_create_empty () from ./usr/lib64/dpdk-19/librte_mempool.so.20.0<= /span>

    #13  r= te_pktmbuf_pool_create_by_ops () from ./usr/lib64/dpdk-19/librte_mbuf.so.20= .0

    #14  r= te_pktmbuf_pool_create () from ./usr/lib64/dpdk-19/librte_mbuf.so.20.0

    #15  d= pdk_create_mbuf_pool (mem_chunk_tbl=3D0x555d556de8e0 , num_mbufs=3D46080, f= rame_len=3D2048, name=3D0x7fff1c1873c0 "DPDK_POOL_0")

 

Is there a bug in DPDK 19.11.5 it crashes when it searches for page= s for POOL creation

 

Please let us know this is second email

 

Thanks

Umakiran

 

From: Umakiran Godavarthi= (ugodavar) <ugodavar@cisco.com>
Date: Wednesday, 14 September 2022 at 1:00 PM
To: anatoly.burakov@intel.com <anatoly.burakov@intel.com>, dev= @dpdk.org <dev@dpdk.org>
Subject: DPDK 19.11.5 Legacy Memory Design Query

Hi Anat= oly/DPDK-Developers

 <= /span>

I am wo= rking on DPDK 19.11.5 Legacy Memory design and have a query about how to bo= ot up in Legacy memory mode.

 


  1. Linux kernel boots up with huge pages (=91N=92) and free huge pages (=91N= =92) initially 

 

  1. We calculate huge pages we need = for data path (Driver need buffers for all queues) by sorting the memory fr= agments 2MB huge pages fragments and find we need =91X=92 pages , so we go to kernel and set SYSFS attribute nr_hugepag= es (/proc/sys/vm/nr_hugepages) to X pages.   We also store= the sorted physical memory fragments as POOL_0, POOL_1, POOL_2=85.etc. (Ju= st for pool count purpose enough for all ports and queues to initialize)

 

For example, if host has memory patter= n huge pages like this for total 500 we get in step 1 kernel reservation.

 

250, 90, 80, 70 , 10= -> Sum is 500 (N pages)

 

We need only 350 pag= es (350 based on no of ports, queues dpdk application needs)

 

So we need 250, 90, = 10.

 

So total 3 pools POO= L_0 -> 250 pages, POOL_1 -> 90, POOL_2 -> 10 pages

 

  1. We boot up DPDK by RTE_EAL_INIT&= nbsp;

 

  1. Then we go to DPDK Memory segmen= t list walkthrough and for each FBARRAY , we find the used pages by DPDK an= d unmap the remaining pages by below 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 unnecessary pages are freed in this step)<= /span>

Sample Code of 4 :

 

           &= nbsp;  rte_me= mseg_list_walk_thread_unsafe(dpdk_find_and_free_unused, NULL); ->DPDK_FI= ND_AND_FREE_UNUSED is called for each Memory segment list (FBARRAY pointer is derived from MSL like below)

 <= /span>

 &= nbsp;            dpd= k_find_and_free_unused(const struct rte_memseg_list *msl,=

  =                      = ;                   void *arg = UNUSED)

 &= nbsp;           &nbs= p; {

 &= nbsp;           &nbs= p;        Int ms_idx;<= /p>

 &= nbsp;           &nbs= p;         arr =3D (struct rte_fbarray *) &am= p;msl->memseg_arr;

 <= /span>

 &= nbsp;           &nbs= p;          /*

 &= nbsp;             &n= bsp;         * use size of 2 i= nstead of 1 to find the next free slot but 

 &= nbsp;             &n= bsp;        * not hole.=

 &= nbsp;            &nb= sp;         */

 &= nbsp;              &= nbsp;    ms_idx =3D rte_fbarray_find_next_n_free(arr, 0= , 2); 

 &= nbsp;           &nbs= p;  

 &= nbsp;           &nbs= p;       if (ms_idx >=3D 0) {<= o:p>

 &= nbsp;            &nb= sp;          addr =3D RTE= _PTR_ADD(msl->base_va, ms_idx * msl->page_sz);

  =                 = ;          munmap(addr, R= TE_PTR_DIFF(RTE_PTR_ADD(msl->base_va, msl->len), addr));<= /o:p>

 &= nbsp;           &nbs= p;        }

 &= nbsp;           &nbs= p; }

 <= /span>

  1. With NR_PAGES As =91X=92 and FREE_PAGES as 0, w= e create MBUF pools using RTE API and we face crash (We take care =91X=94 p= ages has multi pools based on memory fragmentation given to the primary process, so pool by pool we have confidence that DPDK= should find physical memory segment contiguous and allocate successfully)<= /span>

 <= /span>

 &= nbsp;           &nbs= p;      struct rte_mempool *pool;

 <= /span>

  =             &nb= sp;    pool =3D rte_pktmbuf_pool_create(name, num_mbufs,

 &= nbsp;                    =             RTE_MIN(num_mbufs/4, MBUF_CACHE_= SIZE),

 &= nbsp;                    =             MBUF_PRIV_SIZE,

 &= nbsp;                    =             frame_len + RTE_PKTMBUF_HEADROOM= ,

 &= nbsp;                    =             rte_socket_id()

 <= /span>

 &= nbsp;       

  1. Sometimes randomly we face a crash during pool = create in Step 5 for each POOL stored in Step 2 process for all ports and q= ueues initialize later on

 &= nbsp;   

 &= nbsp;           &nbs= p; DPDK EAL core comes with BT like this

 <= /span>

      = ;           <= span style=3D"font-size:10.5pt;font-family:"Helvetica Neue Light"= ;color:#0F0F0F">#6  sigcrash (s= igno=3D11, info=3D0x7fff1c1867f0, ctx=3D0x7fff1c1866c0)

    #7 <= o:p>

    #8  malloc_elem_can_hold () from ./usr/lib64/dp= dk-19/librte_eal.so.20.0

   &nbs= p;#9  find_suitable_element () from ./usr/lib64/dpdk-19/librte_ea= l.so.20.0

   &nbs= p;#10  malloc_heap_alloc () from ./usr/lib64/dpdk-19/librte_eal.s= o.20.0

    #11  r= te_malloc_socket () from ./usr/lib64/dpdk-19/librte_eal.so.20.0=

    #12  r= te_mempool_create_empty () from ./usr/lib64/dpdk-19/librte_mempool.so.20.0<= /span>

    #13  r= te_pktmbuf_pool_create_by_ops () from ./usr/lib64/dpdk-19/librte_mbuf.so.20= .0

    #14  r= te_pktmbuf_pool_create () from ./usr/lib64/dpdk-19/librte_mbuf.so.20.0

    #15  d= pdk_create_mbuf_pool (mem_chunk_tbl=3D0x555d556de8e0 , num_mbufs=3D46080, f= rame_len=3D2048, name=3D0x7fff1c1873c0 "DPDK_POOL_0")

 <= /span>

 &= nbsp;           &nbs= p;  We see find suitable element does not able to find a suitable elem= ent in DPDK memory segment lists it searches for HEAP ALLOC and returns NUL= L and NULL dereference crashes  boot up process

 <= /span>

Please let me know any comments on boot up process for 1-6 and a= ny reason behind the crash ?

 <= /span>

We are = suspecting Step 4 where FBARRAY unused pages freeing at last should free th= e least contiguous memory segments right ? (munmap after finding 2 free pag= es , entire length we unmap in step 4 to free virtual memory)

 <= /span>

Please = let me know thoughts on FBARRAY desi= gn, is it expected to map the most contiguous=85..least contiguous in a vir= tual address space right ?

 <= /span>

So our = most contiguous segments in Step 2 is safe even after Step 3, Step 4 we bel= ieve. Please correct my understanding if anything wrong.<= /p>

 <= /span>

 <= /span>

Thanks<= /span>

Umakira= n

 

--_000_SJ0PR11MB484677FEEE61AD8CF101875CDD4E9SJ0PR11MB4846namp_--