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 C47A3A00C4; Sun, 30 Jan 2022 04:21:26 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5641740E50; Sun, 30 Jan 2022 04:21:26 +0100 (CET) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 73E6C40041; Sun, 30 Jan 2022 04:21:23 +0100 (CET) Received: from dggpemm500021.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4JmbzL0pK4z9sMQ; Sun, 30 Jan 2022 11:19:58 +0800 (CST) Received: from dggpemm100016.china.huawei.com (7.185.36.192) by dggpemm500021.china.huawei.com (7.185.36.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sun, 30 Jan 2022 11:21:21 +0800 Received: from dggpemm500008.china.huawei.com (7.185.36.136) by dggpemm100016.china.huawei.com (7.185.36.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sun, 30 Jan 2022 11:21:20 +0800 Received: from dggpemm500008.china.huawei.com ([7.185.36.136]) by dggpemm500008.china.huawei.com ([7.185.36.136]) with mapi id 15.01.2308.021; Sun, 30 Jan 2022 11:21:20 +0800 From: wangyunjian To: "dev@dpdk.org" , "users@dpdk.org" CC: "feifei.wang2@arm.com" , "ruifeng.wang@arm.com" , Huangshaozhang , dingxiaoxiong Subject: [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: AdgViF0h9zoMAuSNQ6SwzCLA7pDXJw== Date: Sun, 30 Jan 2022 03:21:20 +0000 Message-ID: <61c1d85e0f8a42d4812830864fc59b0a@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.174.242.157] Content-Type: multipart/alternative; boundary="_000_61c1d85e0f8a42d4812830864fc59b0ahuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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_61c1d85e0f8a42d4812830864fc59b0ahuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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_61c1d85e0f8a42d4812830864fc59b0ahuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, all

 

There's a problem that the memo= ry 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_61c1d85e0f8a42d4812830864fc59b0ahuaweicom_-- 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 03E92A04A9; Mon, 31 Jan 2022 05:22:19 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 78188410E0; Mon, 31 Jan 2022 05:22:19 +0100 (CET) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80079.outbound.protection.outlook.com [40.107.8.79]) by mails.dpdk.org (Postfix) with ESMTP id CD7EB40F35; Mon, 31 Jan 2022 05:22:17 +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=RCORWT5h7aos83kaiaIIlzfFEKIb61C29HRotUio9ZA=; b=Pm+F1VzijZVe/9nbnjBVt84SvJxvB+Xw6e4K0Ult1QIFwBt6pyWaHylHd9qTqS7LEKzpscTLDSV4QgiuxXgDw+m9JVoJw4FLqiHJlv0Go5sWVgnV7PX3QOzx9EHL8r0wIR2cblZDI+gdRubAqgxEiHq1pLqrmgfq0Kih+eJwKXU= Received: from DB8PR03CA0019.eurprd03.prod.outlook.com (2603:10a6:10:be::32) by VI1PR08MB3295.eurprd08.prod.outlook.com (2603:10a6:803:4a::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.18; Mon, 31 Jan 2022 04:22:15 +0000 Received: from DB5EUR03FT052.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:be:cafe::a2) by DB8PR03CA0019.outlook.office365.com (2603:10a6:10:be::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.21 via Frontend Transport; Mon, 31 Jan 2022 04:22:14 +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 DB5EUR03FT052.mail.protection.outlook.com (10.152.21.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.15 via Frontend Transport; Mon, 31 Jan 2022 04:22:14 +0000 Received: ("Tessian outbound 18e50a6f0513:v113"); Mon, 31 Jan 2022 04:22:14 +0000 X-CR-MTA-TID: 64aa7808 Received: from cc1ea938b11a.3 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6F19BED3-580E-48E2-9A01-A4C80810E829.1; Mon, 31 Jan 2022 04:22:03 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id cc1ea938b11a.3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 31 Jan 2022 04:22:03 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gWm1bTpFMRMDfyPjzZ7Hr8HiS86zogcYkhtf3AfIPI3/kGi1EC0xN05r3HgizVK4IaqGX4vhGH5wwTR7k2D42X/FokUvdeOqfvFzmVTGkcbBNFjSY8qwu9ZSfsqChp10bm2qnvFrE+pdhGvQrnNT6KUCZ9fnoRKyW+N8TdA+TedIZ/dgrtyBfU/lUFdUviMd8h94D3vPnZYLm1UwHIZtAsju1/s4Mhbkl0z2gfhJFazkkjhghg+KJyJPuQfelvKNLGBuzf7Rs9WY163RNViSy4bsY03qtziAGqU2YwH5G1oeFyTdXaGcE7o2ExZ5AzJwECMiKfm0heTScnUQXVDeSg== 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=RCORWT5h7aos83kaiaIIlzfFEKIb61C29HRotUio9ZA=; b=eKQo0BMqqjqLLlWTUPMGYYZwR3xMI+EK4hUWjQcLUIAG0yWskzzHh7FYK0/r2TxGBKDHPU2HigRqClXMmyKJ4aaFR/7KbHbueeI0E1x3dQ8TkBjCupJfS73c8bnSyjrKO/Mr+CMLP61S2sskB9fLK+uTtT9tbuQZji9wcyLMSy4QmvCuItIAhjJVZ3tsaRS1nY8hxgPpPkzRxmkte9mbYdW2mwYL5rm63FreybBuEJ/1B1c6yo8Vkpzsy0fWH/ZkZljm6Ubg3egxoLHwpUPLpwj/ldBjWXFIprPZEfREeNzU9qtZQZggV1smZ1AmXAsu2NLRktnJf7w3shZdg9wn4w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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=RCORWT5h7aos83kaiaIIlzfFEKIb61C29HRotUio9ZA=; b=Pm+F1VzijZVe/9nbnjBVt84SvJxvB+Xw6e4K0Ult1QIFwBt6pyWaHylHd9qTqS7LEKzpscTLDSV4QgiuxXgDw+m9JVoJw4FLqiHJlv0Go5sWVgnV7PX3QOzx9EHL8r0wIR2cblZDI+gdRubAqgxEiHq1pLqrmgfq0Kih+eJwKXU= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by HE1PR0802MB2490.eurprd08.prod.outlook.com (2603:10a6:3:d9::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4930.20; Mon, 31 Jan 2022 04:21:59 +0000 Received: from DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::7c20:8c83:fc45:db99]) by DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::7c20:8c83:fc45:db99%7]) with mapi id 15.20.4930.021; Mon, 31 Jan 2022 04:21:58 +0000 From: Honnappa Nagarahalli To: wangyunjian , "dev@dpdk.org" , "users@dpdk.org" CC: Feifei Wang , Ruifeng Wang , Huangshaozhang , dingxiaoxiong , Honnappa Nagarahalli , 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: AdgViF0h9zoMAuSNQ6SwzCLA7pDXJwA0WT2g Date: Mon, 31 Jan 2022 04:21:57 +0000 Message-ID: References: <61c1d85e0f8a42d4812830864fc59b0a@huawei.com> In-Reply-To: <61c1d85e0f8a42d4812830864fc59b0a@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 3CB3805F6BEEF0449742AD4370EA7686.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: 649c700c-f40a-4f8c-e7b5-08d9e4714263 x-ms-traffictypediagnostic: HE1PR0802MB2490:EE_|DB5EUR03FT052:EE_|VI1PR08MB3295:EE_ X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: XQsWOqacFfbamkiZz3QkIxEcd0VwCiHdjElG7Z1cc2I2ECKszm+sWs5pQnDwEFr5B8mUIyxp6bB+XPa1pNz7kyU8XvOiAbQGmBa/pjI8YC7qhsdJTgMhS20mf2Drkvj3hZelfuHF6Dk0qQarzr0XrMBV4NOI7uTUbgToih7EUH0KXBC0SkCWUKm3Z75+rrfJ3pv2gC6cp8RYoh/12ofk0mojONAntr5I6VC6R06udLBfXGGWbJPQiAo4okrrgTUqxtQC5ZxFZPwNZqpQNnVhmAOLQmlJaNhNwJ6mjEq1vrck6fCVpXl3OOzlcyE+s0ScPeZV4mdImE+960qL/EYnop1i98RrjRMMpM0pQYgpcuNt3KNsMzAw+NC/qEpAB6Y8n1cr/7RFgNCB/+OkzwcNt/PvrEEXY5LvuXbTiArU8IpRCY1tD48eZeLmT4YXKi7roJDbtaPrJZwP2AurKqJdc5DUd6gJR9fYBRW30HSD2EXjlr1062ZiZ/PYwVd2nbQm96G6m3Orr5wm/2Qtnnmx+yiwzz2spwR3U4vZdYKZW2Km3ZUY/bcNZmhNC6KsMxtSQJuBBd4vJL5nqI5ToDR/qF1xxz6zR9HOr0ttvZAEoLXGxJiOzLe7SP3PuxGa+/bdAA0CSV1ORfYBVIY+1k2NCZkej/FZ1jgHiFy+YoFyzgXlwlKZeqQKGhdPcx33S0/yZDA2qPOLnsKROMO6dgeoVQ== 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)(2906002)(9326002)(4744005)(55016003)(86362001)(5660300002)(52536014)(186003)(26005)(71200400001)(7696005)(9686003)(6506007)(53546011)(4326008)(66476007)(66556008)(66446008)(76116006)(64756008)(66946007)(54906003)(8676002)(316002)(8936002)(33656002)(508600001)(110136005)(38070700005)(122000001)(38100700002)(20210929001); DIR:OUT; SFP:1101; Content-Type: multipart/alternative; boundary="_000_DBAPR08MB58145AE8598C5B3E38A91AF298259DBAPR08MB5814eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2490 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: DB5EUR03FT052.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 1b3fa6ef-4fd8-40ca-0971-08d9e47138ae X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: n63ENgGM+n4lQCuYJ0GD8GRxlb1NjvhiA7qZAeEJUaWDOj91alJIJjqy04GcjjWlkBX3Jl+U4kBc8CwxmbqlbR6QY4Vv/4TrtYTkVP2b+KNEJXz5wRMQYDI/QS9a0YBSbSVGO2Y6WNWWUASm55QXPXrDLGKRQbS8Xg6a20hXztdvOWgUoh1pl0tfNbFcCRb760sNPP4huGOvSMiO+tPbPYYVaULIk7yq/JhVZRS7NiDTk3QsoFPD9b34qbKMtgLQ4nnkZJufAq+WpmGQ1ClyOG9HwKCjs5Ac+iNJqASmiFKfZkb9f1T0wg2OCCnIS7GHLnBIiFtvnJUbdePectpi3l7XxVV4YjuftblUlqD2YLZ66+gc0q+HsKOWl2VZtG4ua86uIf6kMMmUuX6eeYGlcxKasoCN+9ZsVIAtktWEZdNKtrW8s4omcFqKRRAjeWRdi7QhdB0T60L1xgSh6zDzG5L12kc9nPteY1qdjgSsGAfJOHqbuUbtcBhOkJLcApR5X92Z17f7y60qPh4vXTIK1j3fq8mn3p9R3JqeZ8aIZbz6DMPubtNB/eU9FmIU2ZTcM9oPyziZiD1x/hUKhRqU+gMYF5lDzmz5bTyRJtzx/RE+obDXkIQ/AHectL6IiNdK3KdogF04gu+JC4nFlpek5g== 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)(46966006)(36840700001)(53546011)(7696005)(54906003)(26005)(186003)(6506007)(9686003)(316002)(82310400004)(110136005)(86362001)(70206006)(70586007)(8936002)(450100002)(508600001)(356005)(81166007)(36860700001)(336012)(8676002)(47076005)(4326008)(52536014)(9326002)(33656002)(55016003)(2906002)(5660300002)(20210929001); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jan 2022 04:22:14.5760 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 649c700c-f40a-4f8c-e7b5-08d9e4714263 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: DB5EUR03FT052.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3295 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_DBAPR08MB58145AE8598C5B3E38A91AF298259DBAPR08MB5814eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 ; Ruifeng Wang = ; Huangshaozhang ; dingxiaoxiong 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_DBAPR08MB58145AE8598C5B3E38A91AF298259DBAPR08MB5814eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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; users@dpdk.org
Cc: Feifei Wang <Feifei.Wang2@arm.com>; Ruifeng Wang <Ruife= ng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.com>; ding= xiaoxiong <dingxiaoxiong@huawei.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_DBAPR08MB58145AE8598C5B3E38A91AF298259DBAPR08MB5814eurp_-- 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 2F809A034F; Mon, 7 Feb 2022 03:44:03 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A874C4069D; Mon, 7 Feb 2022 03:44:02 +0100 (CET) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by mails.dpdk.org (Postfix) with ESMTP id E4EE940685; Mon, 7 Feb 2022 03:44:00 +0100 (CET) Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4JsVkS4WGFzVfq7; Mon, 7 Feb 2022 10:40:48 +0800 (CST) Received: from dggpemm100016.china.huawei.com (7.185.36.192) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 7 Feb 2022 10:43:58 +0800 Received: from dggpemm500008.china.huawei.com (7.185.36.136) by dggpemm100016.china.huawei.com (7.185.36.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 7 Feb 2022 10:43:57 +0800 Received: from dggpemm500008.china.huawei.com ([7.185.36.136]) by dggpemm500008.china.huawei.com ([7.185.36.136]) with mapi id 15.01.2308.021; Mon, 7 Feb 2022 10:43:57 +0800 From: wangyunjian To: Honnappa Nagarahalli , "dev@dpdk.org" , "users@dpdk.org" CC: Feifei Wang , Ruifeng Wang , Huangshaozhang , dingxiaoxiong , 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: AdgViF0h9zoMAuSNQ6SwzCLA7pDXJwA0WT2gAVxGsfA= Date: Mon, 7 Feb 2022 02:43:57 +0000 Message-ID: References: <61c1d85e0f8a42d4812830864fc59b0a@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.174.242.157] Content-Type: multipart/alternative; boundary="_000_c46f2cfe9ee34d79b7fd80dabc642dcfhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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_c46f2cfe9ee34d79b7fd80dabc642dcfhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 ; dev@dpdk.org; users@dpdk.org Cc: Feifei Wang ; Ruifeng Wang = ; Huangshaozhang ; dingxiaoxiong ; Honnappa Nagarahalli ; 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_c46f2cfe9ee34d79b7fd80dabc642dcfhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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-l= inuxapp-gcc/app/dpdk-testpmd --legacy-mem  -c 0xC  -m 8192

 

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

1 file changed, 14 insertion= s(+)

 

diff --git a/app/test-pmd/te= stpmd.c b/app/test-pmd/testpmd.c

index 55eb293cc0..3c127f9623= 100644

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

+++ b/app/test-p= md/testpmd.c

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

    &nbs= p;             = rte_stats_bitrate_reg(bitrate_data);

    &nbs= p;   }

#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 (in= t 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]);<= o:p>

+    = ;            &n= bsp;         }

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

+    = ;            }<= /o:p>

+    = ;   }

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

+    = ;   return EXIT_SUCCESS;

+

#ifdef RTE_LIB_CMDLINE<= /o:p>

    &nbs= p;   if (strlen(cmdline_filename) !=3D 0)

    &nbs= p;             = cmdline_read_from_file(cmdline_filename);

&n= bsp;

Than= ks,

Yunj= ian

&n= bsp;

From: Honnappa Nagarahalli [mailto:Honnappa.Nagarah= alli@arm.com]
Sent: Monday, January 31, 2022 12:22 PM
To: wangyunjian <wangyunjian@huawei.com>; dev@dpdk.org; users@= dpdk.org
Cc: Feifei Wang <Feifei.Wang2@arm.com>; Ruifeng Wang <Ruife= ng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.com>; ding= xiaoxiong <dingxiaoxiong@huawei.com>; Honnappa Nagarahalli <Honnap= pa.Nagarahalli@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 Y= unjian,

&nbs= p;            &= nbsp;  That’s interesting. Is it possible to elaborate the use c= ase or possibly provide the code snippet?

 

It i= s possible that it is a synchronization problem due to relaxed memory model= that Arm architecture uses. There could be a barrier missing in the code.<= o:p>

 

Than= ks,

Honn= appa

 

From: wangyunjian <wangyunjian@huawei.com>
Sent: Saturday, January 29, 2022 9:21 PM
To: 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>
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 memo= ry 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_c46f2cfe9ee34d79b7fd80dabc642dcfhuaweicom_-- 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 D6CA5A04AD; Tue, 8 Feb 2022 09:01:32 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 779E9410F6; Tue, 8 Feb 2022 09:01:32 +0100 (CET) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by mails.dpdk.org (Postfix) with ESMTP id 8EDC24014E; Tue, 8 Feb 2022 09:01:29 +0100 (CET) Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4JtFj66gBvzZfTS; Tue, 8 Feb 2022 15:57:14 +0800 (CST) Received: from dggpemm500014.china.huawei.com (7.185.36.153) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 8 Feb 2022 16:01:24 +0800 Received: from dggpemm500008.china.huawei.com (7.185.36.136) by dggpemm500014.china.huawei.com (7.185.36.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 8 Feb 2022 16:01:24 +0800 Received: from dggpemm500008.china.huawei.com ([7.185.36.136]) by dggpemm500008.china.huawei.com ([7.185.36.136]) with mapi id 15.01.2308.021; Tue, 8 Feb 2022 16:01:24 +0800 From: wangyunjian To: Honnappa Nagarahalli , "dev@dpdk.org" , "users@dpdk.org" CC: Feifei Wang , Ruifeng Wang , Huangshaozhang , dingxiaoxiong , 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: AdgViF0h9zoMAuSNQ6SwzCLA7pDXJwA0WT2gAVxGsfAAPUvqgA== Date: Tue, 8 Feb 2022 08:01:23 +0000 Message-ID: References: <61c1d85e0f8a42d4812830864fc59b0a@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.174.242.157] Content-Type: multipart/alternative; boundary="_000_b3a5f04f132f4db397004b211084a5achuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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_b3a5f04f132f4db397004b211084a5achuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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; us= ers@dpdk.org Cc: Feifei Wang ; Ruifeng Wang = ; Huangshaozhang ; dingxiaoxiong ; 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_b3a5f04f132f4db397004b211084a5achuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There is also a condition that the hugepagesz is 1G.

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

&n= bsp;

Than= ks,

Yunj= ian

&n= bsp;

From: wangyunjian
Sent: Monday, February 7, 2022 10:44 AM
To: 'Honnappa Nagarahalli' <Honnappa.Nagarahalli@arm.com>; dev= @dpdk.org; users@dpdk.org
Cc: Feifei Wang <Feifei.Wang2@arm.com>; Ruifeng Wang <Ruife= ng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.com>; ding= xiaoxiong <dingxiaoxiong@huawei.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-l= inuxapp-gcc/app/dpdk-testpmd --legacy-mem  -c 0xC  -m 8192

 

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

1 file changed, 14 insertion= s(+)

 

diff --git a/app/test-pmd/te= stpmd.c b/app/test-pmd/testpmd.c

index 55eb293cc0..3c127f9623= 100644

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

+++ b/app/test-p= md/testpmd.c

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

    &nbs= p;             = rte_stats_bitrate_reg(bitrate_data);

    &nbs= p;   }

#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 (in= t 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]);<= o:p>

+    = ;            &n= bsp;         }

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

+    = ;            }<= /o:p>

+    = ;   }

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

+    = ;   return EXIT_SUCCESS;

+

#ifdef RTE_LIB_CMDLINE<= /o:p>

    &nbs= p;   if (strlen(cmdline_filename) !=3D 0)

    &nbs= p;             = cmdline_read_from_file(cmdline_filename);

&n= bsp;

Than= ks,

Yunj= ian

&n= bsp;

From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
Sent: Monday, January 31, 2022 12:22 PM
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>; Honnappa Nagarahalli <Honnappa.Nagarahalli@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 Y= unjian,

&nbs= p;            &= nbsp;  That’s interesting. Is it possible to elaborate the use c= ase or possibly provide the code snippet?

 

It i= s possible that it is a synchronization problem due to relaxed memory model= that Arm architecture uses. There could be a barrier missing in the code.<= o:p>

 

Than= ks,

Honn= appa

 

From: wangyunjian <wangyunjian@huawei.com>
Sent: Saturday, January 29, 2022 9:21 PM
To: 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>
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 memo= ry 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_b3a5f04f132f4db397004b211084a5achuaweicom_-- 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 845E4A0352; Tue, 8 Feb 2022 19:05:12 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4E90641140; Tue, 8 Feb 2022 19:05:12 +0100 (CET) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2054.outbound.protection.outlook.com [40.107.20.54]) by mails.dpdk.org (Postfix) with ESMTP id A77B54111B; Tue, 8 Feb 2022 19:05:11 +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=YAwu7D+I/E4YinmINKwWjp4LWJsy0BbOYncpw4GBfaM=; b=0XBwQqv7q4tFnyh3f7VeHOeqV1+D6HvTi/+CM8BZUQwz6niGgTuyhDlL2ZQy1Y21fViKurmJKMFzUitpxXJdXzi4kyQjUBg4IsA+FRrTqGUgndF76KNtK1FeGTV9/81kkYpdYt0yBZrRHyTRiwad5pFnvo+oz4LmCCAqFMaDQYA= Received: from AS9PR07CA0024.eurprd07.prod.outlook.com (2603:10a6:20b:46c::33) by AS8PR08MB6406.eurprd08.prod.outlook.com (2603:10a6:20b:33c::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Tue, 8 Feb 2022 18:05:10 +0000 Received: from AM5EUR03FT016.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:46c:cafe::a0) by AS9PR07CA0024.outlook.office365.com (2603:10a6:20b:46c::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.11 via Frontend Transport; Tue, 8 Feb 2022 18:05:10 +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 AM5EUR03FT016.mail.protection.outlook.com (10.152.16.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12 via Frontend Transport; Tue, 8 Feb 2022 18:05:10 +0000 Received: ("Tessian outbound 2877e54fe176:v113"); Tue, 08 Feb 2022 18:05:09 +0000 X-CR-MTA-TID: 64aa7808 Received: from 449fe2cc75b5.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D29E6A09-C67D-49A9-A2E0-D4224BC5DE16.1; Tue, 08 Feb 2022 18:05:04 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 449fe2cc75b5.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 08 Feb 2022 18:05:04 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FaLKzHGqLx+HM3PGB/RKfJj+jZ8mLoVXehUQBrT3jZsNLHSuCiR3mAL7yUM4MEAX5F3kLw2fKMWVVgwOq1c6dzpUBlsS/IrnJAjB+bwCAvtqRWZxpP8JwnnGV37AEZWLUYjff17VIwqB3snNwUWyGGoGjannK6XUYYOuPbHjjuuO52aAIu9P5BF05yBvIjdUZSn5dtOKUh57uJLTorkCku7Q+2h+2yKiUb2trU22zfaaakpX+k8c0ZJX4KZYuNt5CJcFse9qic799P5bCfwh0oWqMbOlWcpIuvkuLoRsBBixFS9319ASWRWY9Byots/FUfQoC5UY6RO3dModVFasTA== 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=YAwu7D+I/E4YinmINKwWjp4LWJsy0BbOYncpw4GBfaM=; b=eZTXldbgHflsVrF18bvxeLakXVggWEjSaBcVLsu3wWsvXf6YEzvOj6ainnMEXI/URybHdf6iJS1ITLCKqunjUhTwGD+7QVBw/7yTq3lL256KEMyOptSAWv9HUuHOBA64fXflaZJyeWiO/oSJUQgeab2CPsdrh5NwtYW0wYq48akoiovo/IAADaosl6kxSAOSLenZ2x4Uo2XG40F/Vr/r3VR/U2hqto6nsSzD+S6/TVfSxkuRD2pDAftAWYIee/nEPZFLALnBojcn5eZl0APVhlSgMO2YanDuygh0sMxEMHOH/ke4bS+sTUFAV+G0JXhjq8C1K32wPMR4bh8G5cjxfA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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=YAwu7D+I/E4YinmINKwWjp4LWJsy0BbOYncpw4GBfaM=; b=0XBwQqv7q4tFnyh3f7VeHOeqV1+D6HvTi/+CM8BZUQwz6niGgTuyhDlL2ZQy1Y21fViKurmJKMFzUitpxXJdXzi4kyQjUBg4IsA+FRrTqGUgndF76KNtK1FeGTV9/81kkYpdYt0yBZrRHyTRiwad5pFnvo+oz4LmCCAqFMaDQYA= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by DBBPR08MB4629.eurprd08.prod.outlook.com (2603:10a6:10:f4::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.12; Tue, 8 Feb 2022 18:05:02 +0000 Received: from DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::6d04:5964:7813:4891]) by DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::6d04:5964:7813:4891%4]) with mapi id 15.20.4951.018; Tue, 8 Feb 2022 18:05:01 +0000 From: Honnappa Nagarahalli To: wangyunjian , "dev@dpdk.org" , "users@dpdk.org" CC: Feifei Wang , Ruifeng 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: AdgViF0h9zoMAuSNQ6SwzCLA7pDXJwA0WT2gAVxGsfAAPUvqgAATMLyw Date: Tue, 8 Feb 2022 18:05:00 +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: 4402CFF22DF16D45B22D5A6EEFCA90B6.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: 99beda58-fb9a-4a1c-0408-08d9eb2d8bd8 x-ms-traffictypediagnostic: DBBPR08MB4629:EE_|AM5EUR03FT016:EE_|AS8PR08MB6406:EE_ X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:6430;OLM:6430; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: RPEIZp9YnGjdTwFERIbYn6F2foWrKrHs1K/bFYezZNUV28bJXnPMYs+Wx0wWJ4KpXWxUHf5wOdwiqYaW7nbnpebJVI5Rs950KHtml3r0FeNEagmFkGtBkeCsAGZGjg2L0fsA6RdRWR6qvgRQ0rvOQ7PuPn+D4NUrPdF82Yeh9qQ2+aA5cZS1Sc+IuNZoAJO47kaqJLU/XbJq64nz41O7qgZ8mohtUcNBL1UsHi/yodhDh1Osi/V5y6yVrLTv0UcJaruSgxm030RV+UaIPMKanlQEVb7wLeRVbhqTxHoGiBk4X2qw09x8cZInhD/cKoF3Dr+9uturzFr8xQAX+er/YF6vgyKL6o94fsdQg5f4I/6qlXBjh5ny8OsXN2HALAFvn7RMSE4ts5W1ljGGl+7a9Wsl8yISlVUb231lV+ao8URZz8tpypAZopLSyQwaNt7bu6rHljad8OjFJGA3lIoVGF0OpugXpOY9PDVL32OeFdE+birOdh2jv7QUSR2hwJvuEWIRwuufS5fyRV7ucp5W1ah0L7+kdaTuQyROZI/RpPRw4ZK+7Plj2Uq+VrvN0vl0VQdF21ltPK7gpAAEAFogBwseAJ9ImoXcgFSMnukv7sMQYQuFDY+fghqK7szpObW3t12uWevkrzYrM5PV6AtnoDIYfgTlkIGo/WcQOGvqkY7JNONDhy/GA+vd8+D49alqbgtDi46AipKlq3JpK3lbbQ== 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)(55016003)(66446008)(8936002)(9326002)(64756008)(52536014)(66476007)(66556008)(2906002)(33656002)(508600001)(26005)(8676002)(66946007)(86362001)(38070700005)(110136005)(53546011)(122000001)(9686003)(5660300002)(76116006)(71200400001)(316002)(6506007)(186003)(54906003)(38100700002)(7696005); DIR:OUT; SFP:1101; Content-Type: multipart/alternative; boundary="_000_DBAPR08MB58143CC4AE15DCD6D3DF6C2D982D9DBAPR08MB5814eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBPR08MB4629 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: AM5EUR03FT016.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: cc215219-7a1e-4ca7-09f8-08d9eb2d86ae X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: I1f9rLxVu/JCrLFU65udersvI6/6h5l4MDKpKs0kU9zl3geDsqAQM3NbYQNVWvGNvxhSgIKTNqCiLmYvmBfaVMCtwa2X4QBlxmULR0v2mdUDpFMIo2azEEm9GhxYHHy+W37Ma5crqklxUi6wt+3O9HrFB4zruxSld98XOO7UtmdecgmvldpMxmkaEHWjqwvjBsqq37gP+1HDLxOGWQ/jT/NYuAMrRL5dylyj02kj1dK7GS95fDK9CQMQgi4sCk22RFXuKblvGevJTQLGgbe4PRlm9dC196inXiMVHUo4rM9dyNL2MvE3exdbETA13qjWWdqZR8BRzkY/eL/9T8b+UgxaXZKDnRsvlEs9acuXXc7XY/lGvmLxxe5tFfTP/GKLsN9+sh80bZhY9h6pkb531WSTrdj3BgtA3bhCbFsFdf4bNt9QRj7cYBaWxRKvHS2lUeYFamEYcVOwS1UydVATycVMD9RbQoKTXDvhISnuWSv302UsFsXQocHv+G/8ZSeE9h87Jf8cQ57vcRyb2Ua/Q3DQFvFWSKTUoawq9oWUfp1ZhScfhjJnCfiVwbAj4VYiMrGizwx1xULEIbVY7BNHXRnjXXwacU3IGU03zGCdYDGiAr7RcUlCiB+hR3bPaV+1SqpkibAzuBf8lqtZjUNpWAVOULlIcp2Gnp418hd2ZU1MdnDs+OvDN8SMueHL0L78 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)(46966006)(36840700001)(40470700004)(9686003)(36860700001)(7696005)(82310400004)(316002)(6506007)(356005)(40460700003)(26005)(55016003)(110136005)(54906003)(2906002)(53546011)(33656002)(9326002)(336012)(52536014)(86362001)(47076005)(508600001)(450100002)(4326008)(186003)(8936002)(5660300002)(70206006)(70586007)(8676002)(81166007); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2022 18:05:10.0938 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 99beda58-fb9a-4a1c-0408-08d9eb2d8bd8 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: AM5EUR03FT016.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB6406 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_DBAPR08MB58143CC4AE15DCD6D3DF6C2D982D9DBAPR08MB5814eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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; user= s@dpdk.org Cc: Feifei Wang ; Ruifeng Wang = ; Huangshaozhang ; dingxiaoxiong ; 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_DBAPR08MB58143CC4AE15DCD6D3DF6C2D982D9DBAPR08MB5814eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.com>; dev@d= pdk.org; users@dpdk.org
Cc: Feifei Wang <Feifei.Wang2@arm.com>; Ruifeng Wang <Ruife= ng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.com>; ding= xiaoxiong <dingxiaoxiong@huawei.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 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
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;
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.Nagarahall= i@arm.com]
Sent: Monday, January 31, 2022 12:22 PM
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>; Honnappa Nagarahalli <Honnappa.Nagarahalli@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 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>
Sent: Saturday, January 29, 2022 9:21 PM
To: 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>
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_DBAPR08MB58143CC4AE15DCD6D3DF6C2D982D9DBAPR08MB5814eurp_-- 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 ECB5EA00C2; Thu, 10 Feb 2022 13:11:19 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 91BEC411AE; Thu, 10 Feb 2022 13:11:19 +0100 (CET) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by mails.dpdk.org (Postfix) with ESMTP id 68F884013F; Thu, 10 Feb 2022 13:11:17 +0100 (CET) Received: from dggpemm500024.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4JvbCN36Slz9sZ7; Thu, 10 Feb 2022 20:09:36 +0800 (CST) Received: from dggpemm500014.china.huawei.com (7.185.36.153) by dggpemm500024.china.huawei.com (7.185.36.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 10 Feb 2022 20:11:09 +0800 Received: from dggpemm500008.china.huawei.com (7.185.36.136) by dggpemm500014.china.huawei.com (7.185.36.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Thu, 10 Feb 2022 20:11:08 +0800 Received: from dggpemm500008.china.huawei.com ([7.185.36.136]) by dggpemm500008.china.huawei.com ([7.185.36.136]) with mapi id 15.01.2308.021; Thu, 10 Feb 2022 20:11:08 +0800 From: wangyunjian To: Honnappa Nagarahalli , "dev@dpdk.org" , "users@dpdk.org" CC: "Burakov, Anatoly" , Thomas Monjalon , "sergio.gonzalez.monroy@intel.com" , Feifei Wang , Ruifeng 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: AdgViF0h9zoMAuSNQ6SwzCLA7pDXJwA0WT2gAVxGsfAAPUvqgAATMLywAFSYBYA= Date: Thu, 10 Feb 2022 12:11:08 +0000 Message-ID: References: <61c1d85e0f8a42d4812830864fc59b0a@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.174.242.157] Content-Type: multipart/alternative; boundary="_000_af272100baf845ed9bf754d3b465737ahuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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_af272100baf845ed9bf754d3b465737ahuaweicom_ 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? 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_af272100baf845ed9bf754d3b465737ahuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, = Honnappa

 

The = CPU information is as follows:

Arch= itecture:           =          aarch64<= /p>

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

Byte= Order:           &n= bsp;          Little Endian

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

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

Thre= ad(s) per core:          =     1

Core= (s) per socket:          =     64

Sock= et(s):           &nb= sp;           2

NUMA= node(s):           =          4

Step= ping:           &nbs= p;            0x1

L1d = cache:           &nb= sp;           8 MiB<= /o:p>

L1i = cache:           &nb= sp;           8 MiB<= /o:p>

L2 c= ache:           &nbs= p;            64 MiB=

L3 c= ache:           &nbs= p;            256 Mi= B

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 ha= ve a question, does the dpdk code implement to ensure that the memory initi= alization is 0?

 

Than= ks,

Yunj= ian

&n= bsp;

From: Honnappa Nagarahalli [mailto: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 Y= unjian,

&nbs= p;            &= nbsp; This is not a synchronization problem. The memory is getting allocate= d and used in the same thread. Are you using a single socket system?

 

Than= ks,

Honn= appa

 

From: wangyunjian <<= a href=3D"mailto:wangyunjian@huawei.com">w= angyunjian@huawei.com>
Sent: Tuesday, February 8, 2022 2:01 AM
To: Honnappa Nagarahalli <Honna= ppa.Nagarahalli@arm.com>; dev@dpdk.org; users@dpdk.org
Cc: Feifei Wang <Feifei.Wang2@arm.com>; Ruife= ng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.co= m>; di= ngxiaoxiong <dingxiaoxiong@huawei.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 condition that the hugepagesz is 1G.

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

&n= bsp;

Than= ks,

Yunj= ian

&n= bsp;

From: wangyunjian
Sent: Monday, February 7, 2022 10:44 AM
To: 'Honnappa Nagarahalli' <H= onnappa.Nagarahalli@arm.com>; dev@dpdk.org; users@dpdk.org
Cc: Feifei Wang <Feifei.Wang2@arm.com>; Ruife= ng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.co= m>; di= ngxiaoxiong <dingxiaoxiong@huawei.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-l= inuxapp-gcc/app/dpdk-testpmd --legacy-mem  -c 0xC  -m 8192

 

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

1 file changed, 14 insertion= s(+)

 

diff --git a/app/test-pmd/te= stpmd.c b/app/test-pmd/testpmd.c

index 55eb293cc0..3c127f9623= 100644

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

+++ b/app/test-p= md/testpmd.c

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

    &nbs= p;             = rte_stats_bitrate_reg(bitrate_data);

    &nbs= p;   }

#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 (in= t 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]);<= o:p>

+    = ;            &n= bsp;         }

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

+    = ;            }<= /o:p>

+    = ;   }

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

+    = ;   return EXIT_SUCCESS;

+

#ifdef RTE_LIB_CMDLINE<= /o:p>

    &nbs= p;   if (strlen(cmdline_filename) !=3D 0)

    &nbs= p;             = cmdline_read_from_file(cmdline_filename);

&n= bsp;

Than= ks,

Yunj= ian

&n= bsp;

From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
Sent: Monday, January 31, 2022 12:22 PM
To: wangyunjian <wangyunjian@huawei.c= om>; dev@dpdk.org; users@dpdk.org
Cc: Feifei Wang <Feifei.Wang2@arm.com>; Ruife= ng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.co= m>; di= ngxiaoxiong <dingxiaoxiong@huawei.com>; Honnappa Nagarahalli <Honnappa.Nagara= halli@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 Y= unjian,

&nbs= p;            &= nbsp;  That’s interesting. Is it possible to elaborate the use c= ase or possibly provide the code snippet?

 

It i= s possible that it is a synchronization problem due to relaxed memory model= that Arm architecture uses. There could be a barrier missing in the code.<= o:p>

 

Than= ks,

Honn= appa

 

From: wangyunjian <<= a href=3D"mailto:wangyunjian@huawei.com">w= angyunjian@huawei.com>
Sent: Saturday, January 29, 2022 9:21 PM
To: dev@dpdk.org; users@dpdk.org
Cc: Feifei Wang <Feifei.Wang2@arm.com>; Ruife= ng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.co= m>; di= ngxiaoxiong <dingxiaoxiong@huawei.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 memo= ry 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_af272100baf845ed9bf754d3b465737ahuaweicom_-- 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_-- 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 16D9EA034C; Wed, 23 Feb 2022 12:22:18 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0293E40E5A; Wed, 23 Feb 2022 12:22:18 +0100 (CET) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by mails.dpdk.org (Postfix) with ESMTP id C2F2740DF6; Wed, 23 Feb 2022 12:22:15 +0100 (CET) Received: from dggpemm500022.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4K3YSk4HVPz9sGV; Wed, 23 Feb 2022 19:18:46 +0800 (CST) Received: from dggpemm100014.china.huawei.com (7.185.36.55) by dggpemm500022.china.huawei.com (7.185.36.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 23 Feb 2022 19:22:13 +0800 Received: from dggpemm500008.china.huawei.com (7.185.36.136) by dggpemm100014.china.huawei.com (7.185.36.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Wed, 23 Feb 2022 19:22:13 +0800 Received: from dggpemm500008.china.huawei.com ([7.185.36.136]) by dggpemm500008.china.huawei.com ([7.185.36.136]) with mapi id 15.01.2308.021; Wed, 23 Feb 2022 19:22:13 +0800 From: wangyunjian To: Ruifeng Wang , 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: AdgViF0h9zoMAuSNQ6SwzCLA7pDXJwA0WT2gAVxGsfAAPUvqgAATMLywAFSYBYACWvBhcAA28xwQ Date: Wed, 23 Feb 2022 11:22:12 +0000 Message-ID: <09c3aeaa7bf647f380cce93668759dda@huawei.com> References: <61c1d85e0f8a42d4812830864fc59b0a@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.174.242.157] Content-Type: multipart/alternative; boundary="_000_09c3aeaa7bf647f380cce93668759ddahuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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_09c3aeaa7bf647f380cce93668759ddahuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Ruifeng Wang [mailto:Ruifeng.Wang@arm.com] Sent: Tuesday, February 22, 2022 5:17 PM To: wangyunjian ; Honnappa Nagarahalli ; dev@dpdk.org; users@dpdk.org Cc: Burakov, Anatoly ; thomas@monjalon.net; serg= io.gonzalez.monroy@intel.com; Feifei Wang ; Huangshao= zhang ; dingxiaoxiong = ; nd ; nd ; nd Subject: RE: [dpdk-dev][dpdk-users] A problem about memory may not be all-z= ero allocated by rte_zmalloc_socket() From: wangyunjian > Sent: Thursday, February 10, 2022 8:11 PM To: Honnappa Nagarahalli >; dev@dpdk.org; users@dpdk.org Cc: Burakov, Anatoly >; thomas@monjalon.net; sergio.gonzalez.m= onroy@intel.com; Feifei Wang >; Ruifeng Wang >; Huangshaozhang >; dingxiaoxiong >; 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 [Yunjian] Thanks. However, hugepages are not cleared by the kernel(version = 4.19.90) on the ARM platform. 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_09c3aeaa7bf647f380cce93668759ddahuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

&n= bsp;

&n= bsp;

From: Ruifeng Wang [mailto:Ruifeng.Wang@arm.com]
Sent: Tuesday, February 22, 2022 5:17 PM
To: wangyunjian <wangyunjian@huawei.com>; Honnappa Nagarahalli= <Honnappa.Nagarahalli@arm.com>; dev@dpdk.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>; Huangshaozhang <huangshaozhang@huawei.com>; dingxiaoxiong &= lt;dingxiaoxiong@huawei.com>; nd <nd@arm.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()

 

From: wangyunjian <wangyunjian@huawei.com>
Sent: Thursday, February 10, 2022 8:11 PM
To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>; dev@dpdk.org; users@dpdk.org
Cc: Burakov, Anatoly <anatoly.burakov@intel.com>; thomas@monjalon.net; sergio.gonzalez.monroy@intel.com; Feifei Wang <Feifei.Wang2@arm.com>; Ruifeng Wang <Ruifeng.Wang@arm.com>; Huangshaozha= ng <huangshaozhang@huawei.c= om>; 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, = Honnappa

 

The = CPU information is as follows:

Arch= itecture:           =          aarch64<= /p>

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

Byte= Order:           &n= bsp;          Little Endian

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

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

Thre= ad(s) per core:          =     1

Core= (s) per socket:          =     64

Sock= et(s):           &nb= sp;           2

NUMA= node(s):           =          4

Step= ping:           &nbs= p;            0x1

L1d = cache:           &nb= sp;           8 MiB<= /o:p>

L1i = cache:           &nb= sp;           8 MiB<= /o:p>

L2 c= ache:           &nbs= p;            64 MiB=

L3 c= ache:           &nbs= p;            256 Mi= B

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 ha= ve a question, does the dpdk code implement to ensure that the memory initi= alization is 0?

[Rui= feng] Clearing of the memory should be done by the kernel. In section 3.1.4= .6 of Programmer’s Guide, it says: “

Huge= pages are cleared by the kernel when a file in hugetlbfs or its part is map= ped for the first time system-wide to prevent data leaks from previous user= s of the same hugepage”.

http://doc.dpdk.org/guides/pr= og_guide/env_abstraction_layer.html#memory-mapping-discovery-and-memory-res= ervation

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

Than= ks,

Yunj= ian

&n= bsp;

From: Honnappa Nagarahalli [mailto: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 Y= unjian,

&nbs= p;            &= nbsp; This is not a synchronization problem. The memory is getting allocate= d and used in the same thread. Are you using a single socket system?

 

Than= ks,

Honn= appa

 

From: wangyunjian <<= a href=3D"mailto:wangyunjian@huawei.com">w= angyunjian@huawei.com>
Sent: Tuesday, February 8, 2022 2:01 AM
To: Honnappa Nagarahalli <Honna= ppa.Nagarahalli@arm.com>; dev@dpdk.org; users@dpdk.org
Cc: Feifei Wang <Feifei.Wang2@arm.com>; Ruife= ng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.co= m>; di= ngxiaoxiong <dingxiaoxiong@huawei.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 condition that the hugepagesz is 1G.

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

&n= bsp;

Than= ks,

Yunj= ian

&n= bsp;

From: wangyunjian
Sent: Monday, February 7, 2022 10:44 AM
To: 'Honnappa Nagarahalli' <H= onnappa.Nagarahalli@arm.com>; dev@dpdk.org; users@dpdk.org
Cc: Feifei Wang <Feifei.Wang2@arm.com>; Ruife= ng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.co= m>; di= ngxiaoxiong <dingxiaoxiong@huawei.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-l= inuxapp-gcc/app/dpdk-testpmd --legacy-mem  -c 0xC  -m 8192

 

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

1 file changed, 14 insertion= s(+)

 

diff --git a/app/test-pmd/te= stpmd.c b/app/test-pmd/testpmd.c

index 55eb293cc0..3c127f9623= 100644

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

+++ b/app/test-p= md/testpmd.c

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

    &nbs= p;             = rte_stats_bitrate_reg(bitrate_data);

    &nbs= p;   }

#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 (in= t 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]);<= o:p>

+    = ;            &n= bsp;         }

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

+    = ;            }<= /o:p>

+    = ;   }

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

+    = ;   return EXIT_SUCCESS;

+

#ifdef RTE_LIB_CMDLINE<= /o:p>

    &nbs= p;   if (strlen(cmdline_filename) !=3D 0)

    &nbs= p;             = cmdline_read_from_file(cmdline_filename);

&n= bsp;

Than= ks,

Yunj= ian

&n= bsp;

From: Honnappa Nagarahalli [mailto:Honnappa.Nagarahalli@arm.com]
Sent: Monday, January 31, 2022 12:22 PM
To: wangyunjian <wangyunjian@huawei.c= om>; dev@dpdk.org; users@dpdk.org
Cc: Feifei Wang <Feifei.Wang2@arm.com>; Ruife= ng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.co= m>; di= ngxiaoxiong <dingxiaoxiong@huawei.com>; Honnappa Nagarahalli <Honnappa.Nagara= halli@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 Y= unjian,

&nbs= p;            &= nbsp;  That’s interesting. Is it possible to elaborate the use c= ase or possibly provide the code snippet?

 

It i= s possible that it is a synchronization problem due to relaxed memory model= that Arm architecture uses. There could be a barrier missing in the code.<= o:p>

 

Than= ks,

Honn= appa

 

From: wangyunjian <<= a href=3D"mailto:wangyunjian@huawei.com">w= angyunjian@huawei.com>
Sent: Saturday, January 29, 2022 9:21 PM
To: dev@dpdk.org; users@dpdk.org
Cc: Feifei Wang <Feifei.Wang2@arm.com>; Ruife= ng Wang <Ruifeng.Wang@arm.com>; Huangshaozhang <huangshaozhang@huawei.co= m>; di= ngxiaoxiong <dingxiaoxiong@huawei.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 memo= ry 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_09c3aeaa7bf647f380cce93668759ddahuaweicom_-- 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_-- 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 DB5FB42929; Wed, 12 Apr 2023 19:35:36 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D2AE24111C; Wed, 12 Apr 2023 19:35:33 +0200 (CEST) Received: from mail-pg1-f182.google.com (mail-pg1-f182.google.com [209.85.215.182]) by mails.dpdk.org (Postfix) with ESMTP id C012C410F2 for ; Wed, 12 Apr 2023 19:35:31 +0200 (CEST) Received: by mail-pg1-f182.google.com with SMTP id 41be03b00d2f7-517c86fe6f0so521089a12.3 for ; Wed, 12 Apr 2023 10:35:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; t=1681320931; x=1683912931; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=MsTqOSmE9wXSPFDJSi3RtqcspYxOTUAW4qoWm0L3RlY=; b=MvGS1c+bSDjrHxNwZI/wTrKRMcquyUPEkGysMZ2U8U96ONZtBVitGtR4pYxVLZ2jYn H6ZaWJSxS9zKxuk3Kl5ueIj/OAmxiV43bMlWQOKvgeffDCDEe/cFcwKvHvXvwYFN8/qq TxKBBwqJ2bLQl20l347gvP7JzMD5Gkig5HSGNepDyCb+81HFYsV3+Y20waWB2FExGynI 73Tw6/eT/f51A5CKukoaByjPwKJJXSi6cpH56TfM+auj85jZBZ9UrDVZgDGRJPotYsdc GVLhXLU8laeTSFUKUTiqEdwwiuTtQThTCQX2+RRoGQaZV/HbsbNScWqzv9yeh0ifwVcr 4d/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681320931; x=1683912931; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MsTqOSmE9wXSPFDJSi3RtqcspYxOTUAW4qoWm0L3RlY=; b=Hem9PEpCe0qdJtFxin14V1F06XfmQlLYLMyfKKyOGpzUTfrbgbhdM/gkLMXzVNRQlh BDz5HTGfOS+CsO7+X6jXFnqtglKX5vUIzNdxakViK8dzP+Hj81MhKHQ5kWcgeg1UVJ+/ kt/cW08a21yvNEnm4SvWSpnPFZZ0wi05MELgW17fg8OiF99vdbOsQPryT+PJNCbuPULq 7oFhLBjrC+beNOPAceM+g6ZEE6iDhax9vIxi0gY/RTT7RItIZfLG/pR1m0tNvK7ccvYS vnQKb2mrk3nb+3GYTnIZnGUCtM7E5v5/2px7C75Rd+dp37aT582LoNQGOMCpn+GA/K0M q9VQ== X-Gm-Message-State: AAQBX9c1a6wSrLdQQrm3FyjcT24ipYPFavOYmMUpnivP1+jnEfGQ+U3A ZmcZetiNVyY4T8ISpQ7vTbi39Q== X-Google-Smtp-Source: AKy350YbuLv9E5s2i08F1HPzgnfMThYXINF9aPcMaXYNzQSBlxp0mNKDrt+Jcm86RsihvXfOngD0gA== X-Received: by 2002:a62:7b4e:0:b0:633:afea:6b1a with SMTP id w75-20020a627b4e000000b00633afea6b1amr6567258pfc.19.1681320930785; Wed, 12 Apr 2023 10:35:30 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id u19-20020aa78493000000b0063ac38288b2sm4216488pfn.14.2023.04.12.10.35.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Apr 2023 10:35:30 -0700 (PDT) Date: Wed, 12 Apr 2023 10:35:28 -0700 From: Stephen Hemminger To: Honnappa Nagarahalli Cc: wangyunjian , Ruifeng Wang , "dev@dpdk.org" , "users@dpdk.org" , "Burakov, Anatoly" , "thomas@monjalon.net" , "sergio.gonzalez.monroy@intel.com" , Feifei Wang , Huangshaozhang , dingxiaoxiong , nd Subject: Re: [dpdk-dev][dpdk-users] A problem about memory may not be all-zero allocated by rte_zmalloc_socket() Message-ID: <20230412103528.189db6aa@hermes.local> In-Reply-To: References: <61c1d85e0f8a42d4812830864fc59b0a@huawei.com> <09c3aeaa7bf647f380cce93668759dda@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Wed, 23 Feb 2022 15:38:09 +0000 Honnappa Nagarahalli wrote: > 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 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-mapping-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 when the RTE_MALLOC_DEBUG is enabled. Have you tested with RTE_MALLOC_DEBUG enabled? > > > Thanks, > Yunjian Normally. - hugepage memory is zero'd by kernel when mapped in. DPDK assumes this because the overhead of zeroing large amounts of memory can impact application startup time. If kernel is not zeroing, then your kernel is buggy. - when memory is freed by rte_free() it is set to zero before returning to the pool. - when malloc gets memory it will be zero'd RTE_MALLOC_DEBUG changes this so that: - when memory is freed it gets overwritten by a poison value - when malloc gets memory it will zero it.