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.