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 4E257A034C; Wed, 21 Sep 2022 08:50:37 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id E045E40697; Wed, 21 Sep 2022 08:50:36 +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 BA81F4014F for ; Wed, 21 Sep 2022 08:50:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44990; q=dns/txt; s=iport; t=1663743034; x=1664952634; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=pJn/PbhvsmFi6CH+vtuDDcUcPQ7HDhtxiois6wIo9bw=; b=HEGvjjJX7zDjUwoyi8/wu+XeSx80yK5+FbbQ3Fbo9KffZ8IHjDTP0XRR G8C75nJGLbcWCgcqcUh5hhib29RcUJtpMifsY7B723SR7T/SIvXkrNxY8 3Ay+LpTysBtrafo4JGdwvpywoC50A0zF7s20ZJ9c11rzBIVagOBfdyH9q c=; X-IPAS-Result: =?us-ascii?q?A0AiAgAvsypjmIQNJK1agQmBT4EhMVJ/Alk6RYgaA4Uvi?= =?us-ascii?q?BYDgROaUYEsFIERA1QLAQEBDQEBQgQBAYUFAoRrAiU0CQ4BAgQBAQEBAwIDA?= =?us-ascii?q?QEBAQEBAwEBBQEBAQIBBwQUAQEBAQEBAQEdGQUOECeFaA2GQgEBAQEDDAYVG?= =?us-ascii?q?QEBOA8CAQgRAwECIQENMh0IAgQBEggaglsBghZXAzADAZ8YAYE/AoofeIEBM?= =?us-ascii?q?4EBgggBAQYEBIURGII4CYE9gzGFF4dfJxyBSUSBFUOCMDc+hA8BEgEjHoNug?= =?us-ascii?q?i6ZEgc3A0QdQQMLdgMVAxQDBSQHAxkPIw0NBBYHDAMDBSUDAgIbBwICAwIGE?= =?us-ascii?q?wUCAhc2OAgECAQrJA8FAgcvBQQvAh4EBQYRCAIWAgYEBAQEFQIQCAIIJhcHE?= =?us-ascii?q?zMZAQVZEAkhFgYOGg0FBhMDIEkmBUUPKDJrIgkdGwqBDCoJHxUDBAQDAgYTA?= =?us-ascii?q?wMiAhAqMRQEKRMSLQcrcwkCAyJnBQMDBCgsAwkgBBwHKCY8B1gSKAEEAwMQI?= =?us-ascii?q?j0GAwkDAiRbgQQsKAUDDRkmCAUjFx4ECDwCBQZZmWGCFIFlNQWTSI0/Rp86g?= =?us-ascii?q?TUKg1aJWJZ3FoN2jFCYPpcKIKccAgQCBAUCDgEBBoFhOmtwcBU7gmdRGQ+OL?= =?us-ascii?q?A0Jg1CKXnU7AgYLAQEDCYpnAQE?= IronPort-PHdr: A9a23:4xN7qxzoTFsqh+bXCzPZngc9DxPP8534PQ8Qv5wgjb8GMqGu5I/rM 0GX4/JxxETIUoPW57Mh6aLWvqnsVHZG7cOHt3YPI5BJXgUO3MMRmQFoCcWZCEr9efjtaSFyH MlLWFJ/uX+hNk0AE8flbFqUqXq3vlYv IronPort-Data: A9a23:5QPDha9kxEBNOPJfb+7RDrUDin6TJUtcMsCJ2f8bNWPcYEJGY0x3z TYXUT2GbPbYYWf9eNAjPo7lpEpS6pfQmNBlSFFoqipEQiMRo6IpJzg2wmQcns+2BpeeJK6yx 5xGMrEsFOhtEjmE4E3F3oHJ9RGQ74nQLlbHILOCa3sZqTNMEn9700oywbdh2+aEvPDga++zk YKqyyHgEAfNNw5cagr4PIra9XuDFNyr0N8plgRWicJj5TcypFFJZH4rHpxdGlOjKmVi8kFWc M6YpF2x1juxEx7AkbpJmJ6jGqEBaua60QRjFhO6VoD66iWuqBDe3Y4QK8ACYlt5jw+Wnohal ft3tYXgFQEma/ikdOQ1C3G0Egl3OalAvbTAO3X66JTVxEzdeHyqyPJrZK00FdRHoaAsXycXr rpBc2plghOr34paxJqmRe5gj9oqNuHgPZgUvTdryjSx4fMOEM6bEv+SuI4GtNs2ru5BMcaZb uo9VRBuQS7gQgdtInYcUatryY9EgVGmI2EH9zp5v5Ef72XN5ABp3LurN8DaEvSDQ8xJmUKJ4 Gjb5W36BQ8yNdqDxD7D+XWp7tIjhgvyXIYUUba/7PMv2QXVzW0IAxpQXly+yRWktqKgc/lAE VIf5gQql7czrGf2YOP9Rk3kpnHR63bwROFsO+E97QiMzI/d7ACYGnUIQ1Z9hDoO6ZBeqdsCi wLhoj/5OdB8mObOECvCqN94uRv3aHZLcj5bDcMRZVFdi+QPtr3fmf4mojxLOaqxg9ud9drYn G3S9XNWa1n+cac2O0iT9FTDhXenoYLEC1dtoA7WRWmiqAh+YeZJhrBEC3CGvZ6sz67AETFtW UTofeDFsoji6rnWzUSwrB0lRu3B2hp8GGS0baRTN5cg7S+x3HWoYJpd5jpzTG8wbJhfJ265P hWD4lgMjHO2AJdMRfImC25WI5l6pZUM6fy5PhwpRoMUO8MoJFPvEN9GPBfJjggBb3TAYYlma cvELq5A/F4RCL9sy3KtVvwB3Lowrh3SNkuNLa0XOy+PiOLEDFbMEO9tGALXMogRsvjeyC2Lq Ik3Cid/40gFOAEISnOJodd7wJFjBSVTOK0aXOQOL7XTeVU+Qjp9YxITqJt4E7FYc21uvr+g1 hmAtoVwkTITWVWvxd22V01e IronPort-HdrOrdr: A9a23:NvcP0avE3MgF+KlD5XdWEfXk7skC8YMji2hC6mlwRA09TyXGra 6TdaUguiMc1gx8ZJh5o6H8BEDyewKhyXcV2/haAV7GZmjbUQSTXfhfBOfZsl/d8mjFh5RgPM RbAuVD4b/LfCBHZK/BiWHSebtBsbq6GeKT9JzjJhxWPGVXgtRbnmFE43GgYypLrWd9dP8EPa vZwvACiyureHwRYMj+LGICRfL/q9rCk4+jSQIaBjY8gTP+wQ+A2frfKVy1zx0eWzRAzfMJ6m 7eiTH04a2lrrWS1gLc7WnO9J5b8eGRheerRfb8xPT9GA+cyjpAV74RGIFqewpF4t1H3Wxa0e UkZS1QevibpUmhOl1d6iGdpDUImAxelUMKj2XoxkcKZafCNWsH4w0rv/MeTvKR0TtQgPhslK 1MxG6XrJxREFfJmzn8/cHBU1VwmlOzumdKq59bs5Vza/poVFZql/1owGpFVJMbWC7q4oEuF+ djSMna+fZNaFufK3TUpHNmztCgVmk6Wk7ueDlIhuWFlzxN2HxpxUoRw8IS2n8G6ZImUpFBo+ DJKL5hmr1CRtIfKah9GOACS82qDXGle2OFDEuCZVD8UK0XMXPErJD6pL0z+eGxYZQNiIA/nZ zQOWkowVLau3iefPFm8Kc7gCwlGl/NLQgF4vsulKREhg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.93,332,1654560000"; d="scan'208,217";a="960920596" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Sep 2022 06:50:33 +0000 Received: from mail.cisco.com (xfe-rtp-005.cisco.com [64.101.210.235]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 28L6oW4U014629 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 21 Sep 2022 06:50:33 GMT Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9; Wed, 21 Sep 2022 02:50:31 -0400 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.9 via Frontend Transport; Wed, 21 Sep 2022 01:50:31 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mpZ7HsblO0aus3BLdsOdL1Puj/R8Mp32P4XXM9Ij6N7gDwZ/iqlpPfyHEqpnpDnDGlxRq3uiyzn7EvoxIQ4RCzo/w0k1XfMH90dp0tUK/W2B5zcMNFpzuKRliDcxi/PLgdrvNziO0DZMJElicJlmpjNGfh+myWkEkbAnrPG68OSlRyS5V09A/0mqAFDT+XFD9NYnMwDKd3+KXCnKIXasZ+7KEW68wXkjGH8wWgl6tYxPSQf3NLVu60m6rsACP2W/UKPmy9SNb81sGcCtVpjHjExKr+Aw306S3aJ4Citn5Yx9RR32Fajd1Ivp5Xdo173oQHeYuM4ed7XZWJVcjhUEEQ== 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=mF5i7J4ks85/xajuWWPiXh4ft+DvVKjusCqgBzSMhVA=; b=WPEc0/MjSHZraQJH61qXjCgbM/LJuIDOy3opBSOXAsWSYw1NODneT88SsNGWqotWap+6pxMiVFbi7mSpws4zGzNSGPoKh3pJCDJbPSamtTZJj4HU+j5+tdkCpVs+GCeZRRP9pEcHlXpHGj37MxbF7hgyPX17ISZ+J7X6Rl8dkj9MwXuWn54SbrNTJltMNsrxRRx9Q80jM+JgXgQwMn4vhIg4DV7XCpDpLlpzGqfhrFP4JrYOlZl+KIRxsz6JPiEsGoQBsrCR3RbOZ6S674l26A2KoCZdB+diL/nDA71nIM38GlG/7s00MO/79o5wv6YQhAyLKI0ZwqOI0fFQvBpAjQ== 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=mF5i7J4ks85/xajuWWPiXh4ft+DvVKjusCqgBzSMhVA=; b=jvn8XfLHqO7y5Ftzl5b7/LCaxuZAvuTl4bCYps3rVhnNXUotep0omjJ0J37XSztSDU2KAaGXrv92ZLYdgZmulcwLrSNcZvYYw5nulFVy1lD1Dun9F1GoLUjr3T1LsoyaHXnuWjYLVfzADosSyR8DIfXXg6EbG8+rDNq8F36uh5Y= Received: from SJ0PR11MB4846.namprd11.prod.outlook.com (2603:10b6:a03:2d8::24) by MN0PR11MB6087.namprd11.prod.outlook.com (2603:10b6:208:3cd::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.22; Wed, 21 Sep 2022 06:50:29 +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.014; Wed, 21 Sep 2022 06:50:23 +0000 From: "Umakiran Godavarthi (ugodavar)" To: "anatoly.burakov@intel.com" , "dev@dpdk.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/TnQXrtK3pfBK4 Date: Wed, 21 Sep 2022 06:50:23 +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_|MN0PR11MB6087:EE_ x-ms-office365-filtering-correlation-id: a0928541-5672-4944-4327-08da9b9d8eee x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +6L6IsQhFlOliNfsz6RKh12l3R7V464XHRqdfn+u4gJEc8Sma8zubll0q5C+6/f/+6CYoftRPHs/g+AOdD60YkE/jg7bJdLB4CATUmihAssTKlIsZM7affRy4gT9av3px6DGtj0qI4ZrrA4qpUj0L1v63aNLvJPanBRLwmm5woWiTW9mZ/BS3u0Hyd/RcZ8+A/tTy+nL8kNuP5X1lNkixj/AdevrAOFFU99Dvgv6cV2L7Oh5a66axxYx+jupf9d7NG9S5fFaExCXdXYuNcmlfsiIJ96qDkbt8nm9AA05NXcjPSXjPTEBFR9BjJpnPbC1wTOXRJgG2bHSvYlPKOEbW4C5kh//0ztEWVnaRW7JVVoGyvS9ziVplNOJMg3lDZDu5tyAUkRtFoQ5GjxX6tzpw1j9vVuXQQbh5CnRTZbp5aeIxsmHp9wsleN1jBBZMXbjbfYXFrwk/xDvkgw/tVVaEus+UI2kb5elXWdYuqqELFyglVMrM4qrfydPy+hTcd/1MsYuTHOPfUCDr1wg9pChJPCXh1L0cBCgfbSnZeyuFQr+36SOonM/ermp6C2Jtex/L8pK4DiLZwzUbFWBUz0iK9dW7QqLNZ9N6SjBJQExOjvX+nNw7mKksqh0+5//iGFZYq8ZgrPiNrjdj1y4qhUScRecPdMfQ137wLki5ImfIB/kf0oTx5GyisKFpSuD1KqAdmYUXqzyVntZgJZp3NU3TbkC8PCXxIG8GW7FXTiUXsdEtB40plyWMlWlu6DMPWf+4T8eWvKmmk3UJBAMxVuqSw== 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)(39860400002)(136003)(376002)(346002)(366004)(396003)(451199015)(86362001)(316002)(110136005)(71200400001)(6506007)(66556008)(9686003)(7696005)(91956017)(8936002)(66946007)(41300700001)(5660300002)(66446008)(55236004)(64756008)(76116006)(52536014)(26005)(53546011)(38100700002)(9326002)(8676002)(66476007)(83380400001)(2906002)(38070700005)(186003)(33656002)(478600001)(55016003)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?xky73LV6/o3ok84H7kle5LLx1S8adcIWAZ/+2YF10QkX4fmEx53l99Oo?= =?Windows-1252?Q?LgMa3VXEwMufSAYk3RjeQ51Gy6Q50KPcHZSFhYUOUxmqdicncS2mhxjV?= =?Windows-1252?Q?WiViRZj4rY2ENryu9nVAjsMbqY2tZkOXJAb4d/UIewizzV/1LuY1efRt?= =?Windows-1252?Q?VjqVvZ0Hxd0+oJYW0N3ObuA39J7nAl3TVaT4wS9d2FKx8n5FuoSD27MJ?= =?Windows-1252?Q?orlXoMbZiEsuLS5o7YQlPK1IB2nSp6y1nzQJw6B0WjmnXqA46LjB4gsZ?= =?Windows-1252?Q?FyA350jOiSaaYZPtcVgHKB6Jr8BfYIQsLCHWX8X+Yek8VEU0dU6xuTcP?= =?Windows-1252?Q?sFQKj6kGE3uQvWBlrJhWq4B0uGwePjr2YUjLhTeSifWUvntQ5vCieP2Y?= =?Windows-1252?Q?ukQd3std2XBEevJsBKnvB68iexNlTAAK0aDA5lsiPMkHZIzpzWJR36Q6?= =?Windows-1252?Q?TeyelmuQ5oGtHmtOauOQ57mlj2OGal4Gl7JZD4Tkv4LlL2opSq8EHDZG?= =?Windows-1252?Q?8ipEapDhBLF3Ce4unwJu2LfgZ6w1IA6BsRe/Vk1Rj4HV67aIoIrl8XeB?= =?Windows-1252?Q?Sc9WkaG45dG6juiwAUj074OBkLIK1fuEG+yvR2kXS2giQQuquDwRD6RC?= =?Windows-1252?Q?rzTl5ec0OSIl18AQn8TFsKUfQztlpCd9PpvpDRsliq9jdnmZVdqBOWgz?= =?Windows-1252?Q?UrHIzTgG1u6SWhjRaiU1IHiQGy2lfonOKF/8664UzeHpCuyKafB0VwE6?= =?Windows-1252?Q?LJbziX0GscyyOYprVRWui9MAUB0DYY2Qc+qcjAIqYEoMbQZCGerGAfFg?= =?Windows-1252?Q?6vP/86XgtExL1WzmepjUNHIgKbwmsEOkrzyj7g6kdwnQPaf76+U18o8H?= =?Windows-1252?Q?Rjnp21sMozzLolRtm/BJnmOma1Dd/+aIc1pyNwzAqx59AERbE+vtX6lr?= =?Windows-1252?Q?65M2QkC0IddcUeBTtY1voUEM52uudEPuglmA/8PVM1l5F1LAGKW2pvpv?= =?Windows-1252?Q?bGTvmd0GKT9FwSSZdb4wtq4cvea/4DFcI7scFXpEGNZUm5bJ/3sJwSpV?= =?Windows-1252?Q?CNErn1czxIGnzars3f6AoasKLSrevVRAfIzhgaiwYVVnsi/ktpcocAKC?= =?Windows-1252?Q?Z1DYxYVQ+R1nhuBomrNs7hwjCB0am52TU5XJY4yVv7P5Czj6ilbad8Lu?= =?Windows-1252?Q?wKMtoSRvNsJX2Oy6sxCkLlmpjUmpAubgP939lqwOn1Sffv9DnHV5h+Qx?= =?Windows-1252?Q?mHqT3a4do/IAOsVLWUdLnSBaFeamUqlROQUKFKv456TNpNbBKYlOK5ac?= =?Windows-1252?Q?PRwTI9pbAKUaHY0+2zIXbU2AO6VmWk9tThKwwP6yyRGtL1RrYc9qPqZD?= =?Windows-1252?Q?JsC1lEZ58UerA3SmBGMgd2CNw7/ALUzZRhGr2qkx3XYdIh/OcOinakNy?= =?Windows-1252?Q?KHBobD/+NlvDqzYE/0K7abN/PXk0bHjrnoECTj6v5Irc5hbekbzml4Gg?= =?Windows-1252?Q?UOBe7Dek8Gnq70r8Ap6+hd456eHMZYBmZC3ULACT/z7+3n0NKdJPvYph?= =?Windows-1252?Q?vgxOV25PNBdiCSkwBuVCUVVSFPQdFdV0GfZt0QjBc0NfXi6V9zcJ9oYl?= =?Windows-1252?Q?ggU4CszDKJCO0K8LW1cLQmw0XHoDG0XvIyANI7MQAqxOGjpWlcvw67Fz?= =?Windows-1252?Q?cVrB2sP2nOPAQwUiGaKaKxs39P+Jz7zxhqEN4oalLxQXJS0HYxDv8Q?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_SJ0PR11MB484618A355C51F501B8EC03CDD4F9SJ0PR11MB4846namp_" 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: a0928541-5672-4944-4327-08da9b9d8eee X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2022 06:50:23.6184 (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: KCwUicfnwJIvEIUn1FC6LZ3WdUaisvPS+bfTO0nc+m1thO5UshU2g5mKrD9QsaabM9pcJxS/Vx4QwgOGYgAPZA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN0PR11MB6087 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 64.101.210.235, xfe-rtp-005.cisco.com X-Outbound-Node: alln-core-10.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_SJ0PR11MB484618A355C51F501B8EC03CDD4F9SJ0PR11MB4846namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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_SJ0PR11MB484618A355C51F501B8EC03CDD4F9SJ0PR11MB4846namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Team,

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

your thoughts on this ?<= /span>

 

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 <= span style=3D"font-size:12.0pt;mso-fareast-language:EN-US">

    #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<= /o:p>

    #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)<= o:p>

 &= nbsp;           &nbs= p; {

 &= nbsp;           &nbs= p;        Int ms_idx;

 &= 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) {<= span style=3D"font-size:12.0pt;mso-fareast-language:EN-US">

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

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

 &= 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 <= span style=3D"font-size:12.0pt;mso-fareast-language:EN-US">

    #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<= /o:p>

    #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.

 <= /span>

 <= /span>

Thanks<= /span>

Umakira= n

 

--_000_SJ0PR11MB484618A355C51F501B8EC03CDD4F9SJ0PR11MB4846namp_--