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 DB8E8A00C3; Wed, 23 Feb 2022 16:38:33 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7816C4270F; Wed, 23 Feb 2022 16:38:29 +0100 (CET) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30078.outbound.protection.outlook.com [40.107.3.78]) by mails.dpdk.org (Postfix) with ESMTP id 30373411B2; Wed, 23 Feb 2022 16:38:28 +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=eHEGIRObf8djTfXD1bmisE5nOdlxCKCegTc9mTaIrRI=; b=v4tYqylJmo3QLTGzc3+8uu4+r9fEPFoepPIby+9i6rKjBwsWLCn+3f0eHrl6fGvxZf19VEFNexZkRbJcgC1kcpSZS45C94pj6OHyQK3FtQNYGSZa1q3FEIWYc2GTpRCPSTGORg+nncnLMyhyy/MnAQRzX9RnmlpO3lkNEQO0VsY= Received: from AS9PR0301CA0017.eurprd03.prod.outlook.com (2603:10a6:20b:468::33) by AM0PR08MB3377.eurprd08.prod.outlook.com (2603:10a6:208:d4::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.17; Wed, 23 Feb 2022 15:38:24 +0000 Received: from VE1EUR03FT060.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:468:cafe::2) by AS9PR0301CA0017.outlook.office365.com (2603:10a6:20b:468::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5017.23 via Frontend Transport; Wed, 23 Feb 2022 15:38:24 +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 VE1EUR03FT060.mail.protection.outlook.com (10.152.19.187) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.20 via Frontend Transport; Wed, 23 Feb 2022 15:38:23 +0000 Received: ("Tessian outbound 341d209a0e52:v113"); Wed, 23 Feb 2022 15:38:23 +0000 X-CR-MTA-TID: 64aa7808 Received: from de6d753205a4.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id BE0728C6-9865-4787-A314-D4A94266CB4C.1; Wed, 23 Feb 2022 15:38:14 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id de6d753205a4.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 23 Feb 2022 15:38:14 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=COQh2wYvwkA5M9cCDzGLrgm81XjMCRY58a71Tz5ZGhaW3KT2iqH7faQSd3YviRnACvelFWi58nWZV3hdmWgzjjS36RPZ8+gdVfumm+arUpOQ3ytG24vyNEh/HhbJwQLEZn/Os7EqXno8T5HVaF2qELQ8JqPzxZo3U7//vUpWZ8oN1yY9GEgurpeFWav0U2TmjOAE4BUP+S+1cp1SMfpNrUDObNJPFVViVoctAjsR6ETimmH/j0baqq4oBhC0N8uMGdcIX3LZCRhwcBPzzD3Xg0/hg1YjCvewbD2S0ij4b5gnjMptyzEV/sd4YMbf43JY18KJGeOxvtEEdhujTSBRsg== 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=eHEGIRObf8djTfXD1bmisE5nOdlxCKCegTc9mTaIrRI=; b=KfNnrGkbV9xCbBtGj7XMssJtNqhucXHKe6pgFBzIJ+Q3LnIWIcQ/i2iA27SfGHZfLyetjXMoHTRx3xbBHsj703+30ZHcI1pYIW1hkgnX1U2lznTNQtXijbBMmXc5i96lIhpaPBLRtnFVFEVz8q9hHoXl6FxbnNotblKEBqYdujQtmC5Aby1kYAJRX+VYlcyn9uWwRTFQoESmGf3dztmXflt4zaP5557XRFsPktxJrvU44KzNZUG2Iyn3bI0sFO8wmCdrSUExYDHnWBfHIvtth4U0OqCb5Psi4NDSrqpcR3W69i3HNuNZ8bHfpOjj2d0ANWrGnCTLsSF5lBXEJB04fQ== 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=eHEGIRObf8djTfXD1bmisE5nOdlxCKCegTc9mTaIrRI=; b=v4tYqylJmo3QLTGzc3+8uu4+r9fEPFoepPIby+9i6rKjBwsWLCn+3f0eHrl6fGvxZf19VEFNexZkRbJcgC1kcpSZS45C94pj6OHyQK3FtQNYGSZa1q3FEIWYc2GTpRCPSTGORg+nncnLMyhyy/MnAQRzX9RnmlpO3lkNEQO0VsY= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by VI1PR08MB3567.eurprd08.prod.outlook.com (2603:10a6:803:79::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4995.24; Wed, 23 Feb 2022 15:38:09 +0000 Received: from DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::6d04:5964:7813:4891]) by DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::6d04:5964:7813:4891%5]) with mapi id 15.20.4995.027; Wed, 23 Feb 2022 15:38:09 +0000 From: Honnappa Nagarahalli To: wangyunjian , Ruifeng Wang , "dev@dpdk.org" , "users@dpdk.org" CC: "Burakov, Anatoly" , "thomas@monjalon.net" , "sergio.gonzalez.monroy@intel.com" , Feifei Wang , Huangshaozhang , dingxiaoxiong , 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: AdgViF0h9zoMAuSNQ6SwzCLA7pDXJwA0WT2gAVxGsfAAPUvqgAATMLywAFSYBYACWvBhcAA28xwQAAhQhKA= Date: Wed, 23 Feb 2022 15:38:09 +0000 Message-ID: References: <61c1d85e0f8a42d4812830864fc59b0a@huawei.com> <09c3aeaa7bf647f380cce93668759dda@huawei.com> In-Reply-To: <09c3aeaa7bf647f380cce93668759dda@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: E7B786A2DDFFF4418B22F04B0DA9493B.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: c47b4a53-c1ec-4c87-42eb-08d9f6e2871f x-ms-traffictypediagnostic: VI1PR08MB3567:EE_|VE1EUR03FT060:EE_|AM0PR08MB3377: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: gN35CTbRG3GbrDxGMkVDSAFjPulUmmw3uGBpEYvnbZ5Gaq3xeZwIM37IlI9zVRSWOtV1PZouoPJ5PeW+4JfPfpMg6/AD62UgpV0Cqb+vbCiI3w4WEYZdXCqAKwJRM8EFboQ0KbkBUFGY5AiN1R4e9/SnOZo1/kenkBCAtst5GdwG79QUD9NIi/rpGOlRTH0kyzu8+BtJlHdgYircltSpe+7YTG/g1KUECfQInjBGFqAYIHoLpSTKaeRBg7EDJw+fnVA+aIBluVy61cseomKHsNN2Q4R3XfAgGhJa7Ni2kHM6XNUHCKvUpXHu5c7m4l2AEDSnmvs1qgVk6rTellliniYyKA8f6GIX+ubEuC5vcFun7jo9BBqwk7U+DYG7yDBMWGl0BoOleQRpviQ57aiwwTT7HqhC/xhuhM+MVd/RyGKsHw6BKCcDNrBaRM0FKTc7VFwfv3tTd63TDlDzFkia1er6tYsjfEJG3/nHXMIt6HZqLeGsaBlRgvVcUntetUxVy6LHoWXKdidsUUNpR8JyZi1+v4WIdAbnDBnzOs1NI93TknoU0wu3xCJ3zx4+LQDzWcF5XdoWrdohFFQGl5OQUjni16YOdhWaEbtTT8bLTuHhN3+cMp9eptbhHqozEITUlGlWzflL1a/zU6WQJ4GVN+BeEvI90lmwZgaEnjClsl/DEO7KPP6gwMXSWdR6tngH/s+SZcIom2LDC4mbOimmHrXrgWwMJeWxiX3+zvoSmE5GxmsqpGtWxRd357KFoMV4Zu0A78oL2DkUkrLCcXrtSmQYro+cYBczAHhem+rTo6c= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR08MB5814.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(4326008)(52536014)(38100700002)(166002)(83380400001)(38070700005)(5660300002)(55016003)(2906002)(8936002)(33656002)(26005)(53546011)(54906003)(7696005)(76116006)(966005)(71200400001)(186003)(66556008)(66946007)(9686003)(66476007)(122000001)(8676002)(316002)(110136005)(6506007)(66446008)(64756008)(86362001)(508600001); DIR:OUT; SFP:1101; Content-Type: multipart/alternative; boundary="_000_DBAPR08MB58143D6544E3035F9FA8931E983C9DBAPR08MB5814eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3567 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: VE1EUR03FT060.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 9117e74c-b65b-4e48-a8b2-08d9f6e27ebc X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: E1rkl/HfJpWc9z7DeTIEypxKx68AS6ti/PmJHvyTs0ToBWSpyU5Lhj6MI8C+rnXTGjFyHsLG0hwcbBYgamS+G1FddM2V31tT0xo3T2L4y128bha9d85lEkrqo6iN/g/Sbm4jWTXgLctoF9nAx74oyD2zA9PS1I4Ylw4Kpxpdg1591Vqf8Qv5hrOj95FUerMdHqjz9oPYVzj26XGVY6MnLS41hQ9+Y8bfVjvJ6lilOngdybeMsAhhDkWF+TnNpqhD+BeJ5Uflsg+ldMoGbL5nPNPSQBYhHF0HdEqoj9jHaRyXHHA0dnr68fVhtSTwnLmex5TAOrmWfkR+GBEAY/gLZIXFTXrip14ooyiSnisVKUZ7TR4B9GslZB12CWi89ruzO3O2HmOkE+zYejIIXSkkyl1rqZqpdCv5eV0dWeH4NJPV61XAgOqvmFiSYyKJCHCuq/zvq0e0Xe6n1TFn2dlHZofZbiWf/pdpc0bfUIN51agamcfJiNCOY91HQKAetiIAlHYyCvn68NGNY/0vBiFn8hTna5sFZMgcMge2KXoNVhGc2UDHeVR6rpvaiiwvdvs+klhKErYZS4as+rRBX/Lbkg7JzXwdtEcrtQJUdwepf3Y7ImZosN1QrPqYqUhqFCjaNgq9okfcElvP72yUAdCmOtwYUS4Z/Ii9MOstgPXqIp7eZxpdAgyHxTZQaJ/+C7mSul6UmqC5EbIUJpMom+uad7nptYe46cWo5AU+0BOQ1AI+Yr2F/iVWw4Bmx3ED3RAUZFWQ/c8W6kaW8KXxq8PDMw== 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)(40470700004)(36840700001)(46966006)(36860700001)(8936002)(9686003)(7696005)(6506007)(53546011)(508600001)(5660300002)(52536014)(30864003)(2906002)(166002)(26005)(86362001)(4326008)(8676002)(55016003)(186003)(450100002)(54906003)(47076005)(966005)(110136005)(82310400004)(83380400001)(40460700003)(70206006)(70586007)(81166007)(316002)(33656002)(356005)(336012)(579004); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2022 15:38:23.7931 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c47b4a53-c1ec-4c87-42eb-08d9f6e2871f 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: VE1EUR03FT060.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3377 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_DBAPR08MB58143D6544E3035F9FA8931E983C9DBAPR08MB5814eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 [Yunjian] Thanks. However, hugepages are not cleared by the kernel(version = 4.19.90) on the ARM platform. [Honnappa] I think that is besides the point we are discussing. rte_zmalloc= _socket should be able to zero the memory every time it is called (not just= the first time). I see that rte_zmalloc_socket explicitly clears the memory using memset whe= n the RTE_MALLOC_DEBUG is enabled. Have you tested with RTE_MALLOC_DEBUG en= abled? 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_DBAPR08MB58143D6544E3035F9FA8931E983C9DBAPR08MB5814eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<snip>

 

Hi, Honnappa

 

The CPU information is as follows:

Architecture:         =            aarch64

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

Byte Order:         &n= bsp;            Litt= le Endian

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

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

Thread(s) per core:        =       1

Core(s) per socket:        =       64

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

NUMA node(s):         =            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;      0-31

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

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

NUMA node3 CPU(s):        &= nbsp;      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 s= ection 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 p= revious users of the same hugepage”.

http://doc.dpdk.o= rg/guides/prog_guide/env_abstraction_layer.html#memory-mapping-discovery-an= d-memory-reservation

[Yunjian] Thanks. However, hugepages are not cleared = by the kernel(version 4.19.90) on the ARM platform.

[Honnappa] = I think that is besides the point we are discussing. rte_zmalloc_socket sho= uld be able to zero the memory every time it is called (not just the first = time).

 

I see that rte_zmalloc_socket explicitly clears the memory using me= mset when the RTE_MALLOC_DEBUG is enabled. Have you tested with RTE_MALLOC_= DEBUG enabled?

 

 

Thanks,

Yunjian

 

From: Honnappa Nagarahalli = [mailto:Honnappa.Nagarahall= i@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 not a synchronization problem. The memory is gett= ing allocated and used in the same thread. Are you using a single socket sy= stem?

 

Thanks,

Honnappa

 

From: wangyunjian <wangyunjian@huawei.com<= /a>>
Sent: Tuesday, February 8, 2022 2:01 AM
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; users@dpdk.org<= span style=3D"font-size:11.0pt;mso-fareast-language:ZH-CN">
Cc: Feifei Wang <= Feifei.Wang2@arm.com>; Ruifeng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <hu= angshaozhang@huawei.com>; dingxiaoxiong <dingxiaoxiong@huaw= ei.com>; nd <nd@arm.com&g= t;
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 condition that the hugepagesz is 1G.=

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

 

Thanks,

Yunjian

 

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

 

Hi, Honnappa=

&= nbsp;

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

&= nbsp;

The te= st steps and code are as follows:

&= nbsp;

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

&= nbsp;

app/te= st-pmd/testpmd.c | 14 ++++++++++++++

1 file= changed, 14 insertions(+)

&= nbsp;

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

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

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

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

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

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

+ = ;            &n= bsp;            }

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

+ = ;            &n= bsp;  }

+ = ;      }

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

+ = ;      return EXIT_SUCCESS;

+=

#ifdef= RTE_LIB_CMDLINE

 =        if (strlen(cmdline_filename) !=3D 0)

 =             &nb= sp;    cmdline_read_from_file(cmdline_filename);<= /span>

 

Thanks,

Yunjian

 

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

 

Hi Yunjian,

           &= nbsp;    That’s interesting. Is it possible to elabora= te 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 architecture uses. There could be a barrier missing i= n the code.

 

Thanks,

Honnappa

 

From: wangyunjian <wangyunjian@huawei.com<= /a>>
Sent: Saturday, January 29, 2022 9:21 PM
To: dev@dpdk.org<= /span>; users@dpdk.org<= span style=3D"font-size:11.0pt;mso-fareast-language:ZH-CN">
Cc: Feifei Wang <= Feifei.Wang2@arm.com>; Ruifeng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <hu= angshaozhang@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

&nbs= p;

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

may not b= e all-zero on the ARM platform.

&nbs= p;

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

&nbs= p;

Any id= eas ?

&nbs= p;

Thanks= ,

Yunjia= n

&nbs= p;

--_000_DBAPR08MB58143D6544E3035F9FA8931E983C9DBAPR08MB5814eurp_--