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 6914342929 for ; Wed, 12 Apr 2023 19:35:33 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3243F410F2; Wed, 12 Apr 2023 19:35:33 +0200 (CEST) Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) by mails.dpdk.org (Postfix) with ESMTP id A23FB406A2 for ; Wed, 12 Apr 2023 19:35:31 +0200 (CEST) Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-63238429f87so1118095b3a.0 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=QG5QwJ+OlyXXwGJ5Uq12vP3RJZKLGOJZ/hkOZ3yG6dPANEqACo0/e/0oJiCqiyuEgU pPVlZHk2rkHjd7y7AkWj3t5N1Ktf9rqRCaO146xbCs8lXIq+YYvaNiROKopO+DrPzuk+ xEayvioHQNxEI6etc+yR/NF2NPXSQt0Vf4aNtrU8usUz2xzf1rQZAJccQS7Cph02ajyR RdIFLLzj4tlyPYN34T8YJ9/DWbx4Tt5wBao0NKh5Z5HLQvT2vvYyq1jpYrtGhjYYctSD kilp8STgrDVEgumR8AZt6r/cnb3x9rwXPG4hIXaDKBUuWVNL/tkrKON/gHxRo/pY/XLg F/hg== X-Gm-Message-State: AAQBX9fotRgCI5WpZjTgbfytU6TmzNe8yTWm24DjMnCSOdaz1ttFpvBH q1ZtpZgSikrTAXa/HJzOlruRxg== 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: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-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.