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 2B913A0350; Tue, 22 Feb 2022 10:17:40 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A6DD840DF6; Tue, 22 Feb 2022 10:17:39 +0100 (CET) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2070.outbound.protection.outlook.com [40.107.22.70]) by mails.dpdk.org (Postfix) with ESMTP id 9B65540DF4; Tue, 22 Feb 2022 10:17:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k6v4KNR45W+FL02M4HTWw8wDgF7sU801YCT9t8Y7kdk=; b=qQC0XoJ+Hvs+dVx2j+SQTuFqaNx3sqz4SiSlVo8N9qaZcMUmwyuu+9fL/l17Tw1YybKT6lTUe+lEbZl80t1UqcPgXEEm9N8adaPOUQ3tgCNDfzNwlLEKcV78fxoHoSP0rNj+a/Sc0gy/DkmbJsldLi8Pw/JrMBnDvjf1hlB708g= Received: from AM6P191CA0079.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:8a::20) by DU0PR08MB7413.eurprd08.prod.outlook.com (2603:10a6:10:351::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.24; Tue, 22 Feb 2022 09:17:36 +0000 Received: from VE1EUR03FT040.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8a:cafe::b4) by AM6P191CA0079.outlook.office365.com (2603:10a6:209:8a::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.21 via Frontend Transport; Tue, 22 Feb 2022 09:17:35 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by VE1EUR03FT040.mail.protection.outlook.com (10.152.18.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.20 via Frontend Transport; Tue, 22 Feb 2022 09:17:35 +0000 Received: ("Tessian outbound 826a6d8e58c3:v113"); Tue, 22 Feb 2022 09:17:35 +0000 X-CR-MTA-TID: 64aa7808 Received: from a5e19ad47f1b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C319B296-C0A0-4B2B-A0D4-57FDE8D7814C.1; Tue, 22 Feb 2022 09:17:25 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a5e19ad47f1b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 22 Feb 2022 09:17:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RCelRYoVYSZpNg8o5G2YjAzg791JjSTkXdAqgftf7Du31yzfnqQRfeTIB3UOIpvtaUp4k8H60SzZxJAZYHDZKVxHIavyU0oM7vngQMbOjEFOPV/N+ISYZQzbM/APnnG/Fon8LGW3Fjrx67xq5gh6rHVj/Sx8WQft8zx5x7SyoJe2AQXjGg4eCT0ffcFa7YXtC9ogLR2jfeu+hgFqKHEIa/ZZp2yprPEuwKclbjX/HP9yH8jBtAeF/AVTn94wasTEjOurtryT2Wr/NdLazD4ez2VUHrTThlXDx9A4TGRioBRmqZmZYi6LnQFIWK0upK2En34BbFD4m6+3Xy27LYG5fg== 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=k6v4KNR45W+FL02M4HTWw8wDgF7sU801YCT9t8Y7kdk=; b=cZLj8WuEWI7Mn4GBNqXAEzAS8B7AFvo4/OmgDeN0cNP1EXzhZ/b8/zTtYYQ/+m9+6IvFGBnsGdRPvqrzWVI77J80iZSE4z9bOUVnbjCChT6s42nhWXqI7+4VP2/cEyxGbg33Jbqy6ziG5T9VBgUIN/m5fOirf4UZ04dX9Y7uhUgaKyeQlckNkDlI6AjUd11XP4l7EsCeOMUtD36oTuwjzEhvRyVHorvKQUqD+28vBCo5GeTHbMrhJ9y4/d6qMGedfdULAZT3iz5ob1Bxuaf5am8eJtscN86OwJAlmF5wtFJXMcsToJRegcsVQ26EzVrMEV8SmjgBU6mCfoGJ++HdJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k6v4KNR45W+FL02M4HTWw8wDgF7sU801YCT9t8Y7kdk=; b=qQC0XoJ+Hvs+dVx2j+SQTuFqaNx3sqz4SiSlVo8N9qaZcMUmwyuu+9fL/l17Tw1YybKT6lTUe+lEbZl80t1UqcPgXEEm9N8adaPOUQ3tgCNDfzNwlLEKcV78fxoHoSP0rNj+a/Sc0gy/DkmbJsldLi8Pw/JrMBnDvjf1hlB708g= Received: from AS8PR08MB7080.eurprd08.prod.outlook.com (2603:10a6:20b:401::19) by AM0PR08MB4513.eurprd08.prod.outlook.com (2603:10a6:208:147::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.21; Tue, 22 Feb 2022 09:17:22 +0000 Received: from AS8PR08MB7080.eurprd08.prod.outlook.com ([fe80::480c:9fce:af8a:520e]) by AS8PR08MB7080.eurprd08.prod.outlook.com ([fe80::480c:9fce:af8a:520e%8]) with mapi id 15.20.4995.027; Tue, 22 Feb 2022 09:17:22 +0000 From: Ruifeng Wang To: wangyunjian , Honnappa Nagarahalli , "dev@dpdk.org" , "users@dpdk.org" CC: "Burakov, Anatoly" , "thomas@monjalon.net" , "sergio.gonzalez.monroy@intel.com" , Feifei Wang , Huangshaozhang , dingxiaoxiong , nd , nd , nd Subject: RE: [dpdk-dev][dpdk-users] A problem about memory may not be all-zero allocated by rte_zmalloc_socket() Thread-Topic: [dpdk-dev][dpdk-users] A problem about memory may not be all-zero allocated by rte_zmalloc_socket() Thread-Index: AdgViF0h9zoMAuSNQ6SwzCLA7pDXJwA0WT2gAVxGsfAAPUvqgAATMLywAFSYBYACWvBhcA== Date: Tue, 22 Feb 2022 09:17:22 +0000 Message-ID: References: <61c1d85e0f8a42d4812830864fc59b0a@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: C598250A31A9554FAA51ABC59E08B1C6.0 x-checkrecipientchecked: true Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-MS-Office365-Filtering-Correlation-Id: 9d439a54-a677-461c-e813-08d9f5e42a01 x-ms-traffictypediagnostic: AM0PR08MB4513:EE_|VE1EUR03FT040:EE_|DU0PR08MB7413:EE_ x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: LMX7veZnTmILp9AombdTJ2g+/8wuOOe2dsRd5Xju3aXal/qDit2wndjooURHOMCLuqLEjWXm3EHZrfYEMsrT4cevBA39c5GD0EFCYGOq86SjToAMumq1rXZoy4l3eWsr2KsLwTzMScUNTJfsDI63VCrwGFAEVD8ombBrB8DA+IQi/bGdFDYicl/u3aeqwARfU/SrA883tYJz/fejCJkO1BGCIQYwweb3x0N9oaS1GBE0ejuO2GljQya//viFZNPnhIJs7Mi0a/I0ONUCBTKpmcVhmm1zodhWkZ5/RlL3A968SbzNI5PVbjASpjs07kPbrmVVEznfDt4cZnR1Us9T0r5/DWAMa0Spks3JJdt6hfZZUiDb1Cd92CVOvLcv+2Tjjbk0uVCdevvwPFSe1lW/hYzoeBAJ0LAymbmZS3Bn474TI7jv8UK9rKINywmiFSyqwcbTBptZf1ZbDPTd8PzMC0VXTWx6yO3JOlGPUJsuL2LgsiT+XNcmYp7KuKn5KaM2ceRw4hrZOGd3xiZ8LYL2oq5q8kg+4AFtEcLgrbWFbgtFMpDFXOHGCcEzP812yqxKJVucFwzHa84fUq4BVXnBUjhpMVt6FkPUTxnUhWcFfZjInuOFTLgmKg6Mao7TLBNyAOZL7M5JDdnxOPC+yvZTh/27vjpr8zP7JQrontpoHgs1YksR34IMFXxrWopmvH36E3vp7U1yGoqA44+DMdFUe4+JR+YkRqmkANCz8wvoRcyKliO6ipjeMGBI+BTkvvlO8HVlAwbrijXvvyFNwd9WLZ9359z+evo21P4oy3MxtdA= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR08MB7080.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(54906003)(110136005)(33656002)(83380400001)(86362001)(26005)(38070700005)(186003)(53546011)(5660300002)(508600001)(8936002)(66446008)(966005)(76116006)(66946007)(64756008)(7696005)(6506007)(4326008)(66476007)(8676002)(2906002)(38100700002)(316002)(166002)(52536014)(71200400001)(66556008)(55016003)(9686003)(122000001); DIR:OUT; SFP:1101; Content-Type: multipart/alternative; boundary="_000_AS8PR08MB7080C740C3A1A5C003F890479E3B9AS8PR08MB7080eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4513 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT040.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 937d29ca-416e-4478-7403-08d9f5e42244 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FcZxP+mVT6X47PRCjyddSHtyZrp2zP2SFcU3gnqw+VABET1GNNV0X8QZkwxJ2LzqD5BVxSVE43OBTm8OgF5OxOtAB1ZFV/UxvghAl05SQgGSuRk4o0HhSImNxVg1ycjOg9z2+hGT1qsrtR+JL3r+yZAyHbfsD3CTgEI+udytWz6ftoO72JLQicUCAb8+0W+sRKkNguWWvwnjOUJhca9FUoJ4N9RY/u6jmrtlR2yTUP4HxeLqcIGmne5uaoRZfQkfB63FbJOQPxZ8NPJD9BwkVt1MGImtWlNHMo1sc0+V4PZNb78r8HEFql42e1YpLmdRoCXRaffw8ociq0R3nL1fe5zPgmu5zU64Ya1pbGZVPBjT8x8uOvhjVQrWWVO1yxYzDq9BDkZE6IAFxSYeKLwwPGjXiBj+52dYV3fUnWuOmIcUjUcrkPP55PXc8I5MwfIw9aDmugN0lmK4oj7DIidS9EQuofG00Z7x4iSVsnOUDpx2Sx26XpkIFTUf8TwbwFxdF1waNGm4vJoDGFZ862Iw3W4CVPz1n9srVR7EAGuD/xp6P1BuxqcUb8+Fh5kVDdOgKsHKSDIi8Mys00wTF/JqRPGBE7TWDuO9EcAJK4+hywzhnxYGxgO3l5uZg/tCd9aAhhLHT4yPvx43pTnhcxc71e4JI7UG3A9XxI2IooippJOAvE7mw0RZtzqxVPZ97fu2TUlRvGimJONW1Z4+7f3Se+cc7dU4f7XCMBoU+7ihdnu9Tk6Ac5Z+nqshgQVwu1oDesTslTHCcO9t6vu+j6Vx+w== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230001)(4636009)(36840700001)(46966006)(40470700004)(82310400004)(450100002)(70586007)(8676002)(316002)(70206006)(86362001)(8936002)(966005)(336012)(52536014)(7696005)(4326008)(6506007)(53546011)(508600001)(54906003)(110136005)(81166007)(9686003)(26005)(166002)(186003)(356005)(2906002)(33656002)(55016003)(36860700001)(40460700003)(47076005)(83380400001)(5660300002)(30864003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2022 09:17:35.3900 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9d439a54-a677-461c-e813-08d9f5e42a01 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT040.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR08MB7413 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_AS8PR08MB7080C740C3A1A5C003F890479E3B9AS8PR08MB7080eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: wangyunjian Sent: Thursday, February 10, 2022 8:11 PM To: Honnappa Nagarahalli ; dev@dpdk.org; user= s@dpdk.org Cc: Burakov, Anatoly ; thomas@monjalon.net; serg= io.gonzalez.monroy@intel.com; Feifei Wang ; Ruifeng W= ang ; Huangshaozhang ; din= gxiaoxiong ; nd ; nd Subject: RE: [dpdk-dev][dpdk-users] A problem about memory may not be all-z= ero allocated by rte_zmalloc_socket() Hi, Honnappa The CPU information is as follows: Architecture: aarch64 CPU op-mode(s): 64-bit Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 1 Core(s) per socket: 64 Socket(s): 2 NUMA node(s): 4 Stepping: 0x1 L1d cache: 8 MiB L1i cache: 8 MiB L2 cache: 64 MiB L3 cache: 256 MiB NUMA node0 CPU(s): 0-31 NUMA node1 CPU(s): 32-63 NUMA node2 CPU(s): 64-95 NUMA node3 CPU(s): 96-127 I have a question, does the dpdk code implement to ensure that the memory i= nitialization is 0? [Ruifeng] Clearing of the memory should be done by the kernel. In section 3= .1.4.6 of Programmer's Guide, it says: " Hugepages are cleared by the kernel when a file in hugetlbfs or its part is= mapped for the first time system-wide to prevent data leaks from previous = users of the same hugepage". http://doc.dpdk.org/guides/prog_guide/env_abstraction_layer.html#memory-map= ping-discovery-and-memory-reservation Thanks, Yunjian From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com] Sent: Wednesday, February 9, 2022 2:05 AM To: wangyunjian >; de= v@dpdk.org; users@dpdk.org Cc: Feifei Wang >; Ruifen= g Wang >; Huangshaozhang = >; dingxiaoxion= g >; nd >; nd > Subject: RE: [dpdk-dev][dpdk-users] A problem about memory may not be all-z= ero allocated by rte_zmalloc_socket() Hi Yunjian, This is not a synchronization problem. The memory is getting= allocated and used in the same thread. Are you using a single socket syste= m? Thanks, Honnappa From: wangyunjian > Sent: Tuesday, February 8, 2022 2:01 AM To: Honnappa Nagarahalli >; dev@dpdk.org; users@dpdk.org Cc: Feifei Wang >; Ruifen= g Wang >; Huangshaozhang = >; dingxiaoxion= g >; nd > Subject: RE: [dpdk-dev][dpdk-users] A problem about memory may not be all-z= ero allocated by rte_zmalloc_socket() There is also a condition that the hugepagesz is 1G. If the hugepagesz is 2M, this problem cannot be repeated. Thanks, Yunjian From: wangyunjian Sent: Monday, February 7, 2022 10:44 AM To: 'Honnappa Nagarahalli' >; dev@dpdk.org; users@dpdk.org Cc: Feifei Wang >; Ruifen= g Wang >; Huangshaozhang = >; dingxiaoxion= g >; nd > Subject: RE: [dpdk-dev][dpdk-users] A problem about memory may not be all-z= ero allocated by rte_zmalloc_socket() Hi, Honnappa This problem is probability. Test case need to be executed multiple times. The test steps and code are as follows: /home/dpdk #./arm64-armv8a-linuxapp-gcc/app/dpdk-testpmd --legacy-mem -c 0= xC -m 8192 app/test-pmd/testpmd.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c index 55eb293cc0..3c127f9623 100644 --- a/app/test-pmd/testpmd.c +++ b/app/test-pmd/testpmd.c @@ -4251,6 +4251,20 @@ main(int argc, char** argv) rte_stats_bitrate_reg(bitrate_data); } #endif + + printf("start test rte_zmalloc_socket\n"); + char *a; + while((a =3D rte_zmalloc_socket(NULL, 1024 * 1024, 0, SOCKET_ID_ANY= )) !=3D NULL) { + for (int i =3D 0; i < 1024 * 1024; i++) { + if (a[i] !=3D 0) { + printf("a[%d] =3D %d\n",i,a[i]); + } + a[i] =3D 255; // This assignment is important. I= t can increase the probability. + } + } + printf("end test rte_zmalloc_socket\n"); + return EXIT_SUCCESS; + #ifdef RTE_LIB_CMDLINE if (strlen(cmdline_filename) !=3D 0) cmdline_read_from_file(cmdline_filename); Thanks, Yunjian From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com] Sent: Monday, January 31, 2022 12:22 PM To: wangyunjian >; de= v@dpdk.org; users@dpdk.org Cc: Feifei Wang >; Ruifen= g Wang >; Huangshaozhang = >; dingxiaoxion= g >; Honnappa Nag= arahalli = >; nd > Subject: RE: [dpdk-dev][dpdk-users] A problem about memory may not be all-z= ero allocated by rte_zmalloc_socket() Hi Yunjian, That's interesting. Is it possible to elaborate the use cas= e or possibly provide the code snippet? It is possible that it is a synchronization problem due to relaxed memory m= odel that Arm architecture uses. There could be a barrier missing in the co= de. Thanks, Honnappa From: wangyunjian > Sent: Saturday, January 29, 2022 9:21 PM To: dev@dpdk.org; users@dpdk.org Cc: Feifei Wang >; Ruifen= g Wang >; Huangshaozhang = >; dingxiaoxion= g > Subject: [dpdk-dev][dpdk-users] A problem about memory may not be all-zero = allocated by rte_zmalloc_socket() Hi, all There's a problem that the memory are allocated by rte_zmalloc_socket() may not be all-zero on the ARM platform. However, the x86 platform does not have this problem. Any ideas ? Thanks, Yunjian --_000_AS8PR08MB7080C740C3A1A5C003F890479E3B9AS8PR08MB7080eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: = wangyunjian <wangyunjian@huawei.com>
Sent: Thursday, February 10, 2022 8:11 PM
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; dev@d= pdk.org; users@dpdk.org
Cc: Burakov, Anatoly <anatoly.burakov@intel.com>; thomas@monja= lon.net; sergio.gonzalez.monroy@intel.com; Feifei Wang <Feifei.Wang2@arm= .com>; Ruifeng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <hua= ngshaozhang@huawei.com>; dingxiaoxiong <dingxiaoxiong@huawei.com>; nd <nd@arm.com>; nd <nd@arm.com>
Subject: RE: [dpdk-dev][dpdk-users] A problem about memory may not b= e all-zero allocated by rte_zmalloc_socket()

 =

Hi, Honnappa

 

The CPU information= is as follows:

Architecture: =             &nb= sp;      aarch64

CPU op-mode(s):&nbs= p;            &= nbsp;    64-bit

Byte Order: &n= bsp;            = ;        Little Endian=

CPU(s):  =             &nb= sp;           128

On-line CPU(s) list= :             0= -127

Thread(s) per core:=             &nb= sp; 1

Core(s) per socket:=             &nb= sp; 64

Socket(s): &nb= sp;            =          2

NUMA node(s): =             &nb= sp;      4

Stepping: &nbs= p;            &= nbsp;         0x1=

L1d cache: &nb= sp;            =          8 MiB

L1i cache: &nb= sp;            =          8 MiB

L2 cache: &nbs= p;            &= nbsp;         64 MiB

L3 cache: &nbs= p;            &= nbsp;         256 MiB

NUMA node0 CPU(s):&= nbsp;           &nbs= p;  0-31

NUMA node1 CPU(s):&= nbsp;           &nbs= p;  32-63

NUMA node2 CPU(s):&= nbsp;           &nbs= p;  64-95

NUMA node3 CPU(s):&= nbsp;           &nbs= p;  96-127

 

I have a question, = does the dpdk code implement to ensure that the memory initialization is 0?=

[Ruifeng] Clearing = of the memory should be done by the kernel. In section 3.1.4.6 of Programme= r’s Guide, it says: “

Hugepages are clear= ed by the kernel when a file in hugetlbfs or its part is mapped for the fir= st time system-wide to prevent data leaks from previous users of the same h= ugepage”.

http://doc.dpdk.org/guides/prog_guide/env_ab= straction_layer.html#memory-mapping-discovery-and-memory-reservation

 

Thanks,<= /span>

Yunjian<= /span>

 

From: = Honnappa Nagarahalli [mailt= o:Honnappa.Nagarahalli@arm.com]
Sent: Wednesday, February 9, 2022 2:05 AM
To: wangyunjian <wangyu= njian@huawei.com>; dev@dpdk.org; users@dpdk.org
Cc: Feifei Wang <Feifei.W= ang2@arm.com>; Ruifeng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.com>; dingxiaoxiong <dingxiaoxion= g@huawei.com>; nd <nd@arm.com&g= t;; nd <nd@arm.com>
Subject: RE: [dpdk-dev][dpdk-users] A problem about memory may not b= e all-zero allocated by rte_zmalloc_socket()

 =

Hi Yunjian,

   &= nbsp;           This is n= ot a synchronization problem. The memory is getting allocated and used in t= he same thread. Are you using a single socket system?

 

Thanks,<= /span>

Honnappa=

 

From: = wangyunjian <wangyunjian@huawei.com>
Sent: Tuesday, February 8, 2022 2:01 AM
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.c= om>; dev= @dpdk.org; u= sers@dpdk.org
Cc: Feifei Wang <<= span style=3D"font-size:11.0pt">Feifei.Wang2@arm.com>; Ruifeng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.com>; dingxiaoxiong <dingxiaoxiong@huaw= ei.com>; nd <nd@arm.com>
Subject: RE: [dpdk-dev][dpdk-users] A problem about memory may not b= e all-zero allocated by rte_zmalloc_socket()

 =

There is also a cond= ition that the hugepagesz is 1G.

If the hugepagesz is= 2M, this problem cannot be repeated.

 

Thanks,<= /span>

Yunjian<= /span>

 

From: = wangyunjian
Sent: Monday, February 7, 2022 10:44 AM
To: 'Honnappa Nagarahalli' <Honnappa.Nagarahalli@arm= .com>; dev= @dpdk.org; u= sers@dpdk.org
Cc: Feifei Wang <<= span style=3D"font-size:11.0pt">Feifei.Wang2@arm.com>; Ruifeng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.com>; dingxiaoxiong <dingxiaoxiong@huaw= ei.com>; nd <nd@arm.com>
Subject: RE: [dpdk-dev][dpdk-users] A problem about memory may not b= e all-zero allocated by rte_zmalloc_socket()

 =

Hi, Honnappa

 

This problem is probability. Test case need to be= executed multiple times.

 

The test steps and code are as follows:

 

/home/dpdk #./arm64-armv8a-linuxapp-gcc/app/dpdk-= testpmd --legacy-mem  -c 0xC  -m 8192

 

app/test-pmd/testpmd.c | 14 ++++++++++++++

1 file changed, 14 insertions(+)

 

diff --git a/app/test-pmd/testpmd.c b/app/test-pm= d/testpmd.c

index 55eb293cc0..3c127f9623 100644

--- a/app/test-pmd/testpmd.c

+++ b/app/test-pmd/testpmd.c

@@ -4251,6 +4251,20 @@ main(int argc, char** argv= )

        &= nbsp;         rte_stats_bitrate_reg= (bitrate_data);

        }=

#endif

+

+       printf(&quo= t;start test rte_zmalloc_socket\n");

+       char *a;

+       while((a = =3D rte_zmalloc_socket(NULL, 1024 * 1024, 0, SOCKET_ID_ANY)) !=3D NULL) {

+        =         for (int i =3D 0; i < 1024 * = 1024; i++) {

+        =             &nb= sp;     if (a[i] !=3D 0) {

+        =             &nb= sp;            =   printf("a[%d] =3D %d\n",i,a[i]);

+        =             &nb= sp;     }

+        =             &nb= sp;     a[i] =3D 255; // This assignment is important. = It can increase the probability.

+        =         }

+       }

+       printf(&quo= t;end test rte_zmalloc_socket\n");

+       return EXIT= _SUCCESS;

+

#ifdef RTE_LIB_CMDLINE

        if (st= rlen(cmdline_filename) !=3D 0)

        &= nbsp;         cmdline_read_from_fil= e(cmdline_filename);

 

Thanks,<= /span>

Yunjian<= /span>

 

From: = Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
Sent: Monday, January 31, 2022 12:22 PM
To: wangyunjian <wangyunjian@huawei.com>; dev= @dpdk.org; u= sers@dpdk.org
Cc: Feifei Wang <<= span style=3D"font-size:11.0pt">Feifei.Wang2@arm.com>; Ruifeng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.com>; dingxiaoxiong <dingxiaoxiong@huaw= ei.com>; Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com<= /a>>; nd <nd@arm.com>
Subject: RE: [dpdk-dev][dpdk-users] A problem about memory may not b= e all-zero allocated by rte_zmalloc_socket()

 =

Hi Yunjian,

   &= nbsp;            Tha= t’s interesting. Is it possible to elaborate the use case or possibly= provide the code snippet?

 

It is possible that= it is a synchronization problem due to relaxed memory model that Arm archi= tecture uses. There could be a barrier missing in the code.

 

Thanks,<= /span>

Honnappa=

 

From: = wangyunjian <wangyunjian@huawei.com>
Sent: Saturday, January 29, 2022 9:21 PM
To: dev@dpdk.org; u= sers@dpdk.org
Cc: Feifei Wang <<= span style=3D"font-size:11.0pt">Feifei.Wang2@arm.com>; Ruifeng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.com>; dingxiaoxiong <dingxiaoxiong@huaw= ei.com>
Subject: [dpdk-dev][dpdk-users] A problem about memory may not be al= l-zero allocated by rte_zmalloc_socket()

 =

Hi, all

 

There's a problem that the memory are allocated by r= te_zmalloc_socket()

may not be all-zero on the ARM platform.<= /p>

 

However, the x86 platform does not have this problem= .

 

Any ideas ?

 

Thanks,

Yunjian

 

--_000_AS8PR08MB7080C740C3A1A5C003F890479E3B9AS8PR08MB7080eurp_--