From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id CB1C95A35 for ; Thu, 19 Nov 2015 07:09:54 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 18 Nov 2015 22:09:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,316,1444719600"; d="scan'208";a="842097698" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by fmsmga001.fm.intel.com with ESMTP; 18 Nov 2015 22:09:36 -0800 Received: from FMSMSX109.amr.corp.intel.com (10.18.116.9) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 18 Nov 2015 22:09:35 -0800 Received: from shsmsx103.ccr.corp.intel.com (10.239.4.69) by fmsmsx109.amr.corp.intel.com (10.18.116.9) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 18 Nov 2015 22:09:35 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.83]) by SHSMSX103.ccr.corp.intel.com ([169.254.4.138]) with mapi id 14.03.0248.002; Thu, 19 Nov 2015 14:09:28 +0800 From: "Xie, Huawei" To: "Wang, Zhihong" , "Mcnamara, John" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling Thread-Index: AdEh+cDyRRUaxKXlTJiv4jhXXCoSSw== Date: Thu, 19 Nov 2015 06:09:27 +0000 Message-ID: References: <1447817231-10510-1-git-send-email-zhihong.wang@intel.com> <1447817231-10510-3-git-send-email-zhihong.wang@intel.com> <8F6C2BD409508844A0EFC19955BE094183467C@SHSMSX152.ccr.corp.intel.com> <8F6C2BD409508844A0EFC19955BE0941834AFE@SHSMSX152.ccr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 06:09:55 -0000 On 11/19/2015 11:54 AM, Wang, Zhihong wrote:=0A= >=0A= >> -----Original Message-----=0A= >> From: Xie, Huawei=0A= >> Sent: Wednesday, November 18, 2015 8:08 PM=0A= >> To: Wang, Zhihong ; Mcnamara, John=0A= >> ; dev@dpdk.org=0A= >> Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessa= ry=0A= >> hugepage zero-filling=0A= >>=0A= >> On 11/18/2015 6:45 PM, Wang, Zhihong wrote:=0A= >>>> -----Original Message-----=0A= >>>> From: Mcnamara, John=0A= >>>> Sent: Wednesday, November 18, 2015 6:40 PM=0A= >>>> To: Wang, Zhihong ; dev@dpdk.org=0A= >>>> Subject: RE: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove=0A= >>>> unnecessary hugepage zero-filling=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>>> -----Original Message-----=0A= >>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zhihong Wang=0A= >>>>> Sent: Wednesday, November 18, 2015 3:27 AM=0A= >>>>> To: dev@dpdk.org=0A= >>>>> Subject: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove=0A= >>>>> unnecessary hugepage zero-filling=0A= >>>>>=0A= >>>>> The kernel fills new allocated (huge) pages with zeros.=0A= >>>>> DPDK just has to touch the pages to trigger the allocation.=0A= >> I think we shouldn't reply on the assumption that kernel has zeroed the = memory.=0A= > I understand the concern.=0A= > In my opinion application shouldn't assume malloced memory to be zero-fil= led. So it should be okay for DPDK even if the kernel doesn't zero the page= at all.=0A= For malloc, we shouldn't make this assumption because it might allocate=0A= just freed memory from the heap. Hugetlbfs is different. Let us listen=0A= to other people's opinion.=0A= It will make life much easier if we could make this assumption.=0A= >=0A= > I agree that we should check if any code accidentally make that assumptio= n. Currently there's rte_pktmbuf_init() for packet mbuf initialization.=0A= >=0A= > /Zhihong=0A= >=0A= >=0A= >> Kernel zeroes the memory mostly to avoid information leakage.It could al= so=0A= >> achieve this by setting each bit to 1.=0A= >> What we indeed need to check is later DPDK initialization code doesn't a= ssume=0A= >> the memory has been zeroed. Otherwise zero only that part of the memory.= =0A= >> Does this makes sense?=0A= >>=0A= >>>>> ...=0A= >>>>> if (orig) {=0A= >>>>> hugepg_tbl[i].orig_va =3D virtaddr;=0A= >>>>> - memset(virtaddr, 0, hugepage_sz);=0A= >>>>> + memset(virtaddr, 0, 8);=0A= >>>>> }=0A= >>>> Probably worth adding a one or two line comment here to avoid someone= =0A= >>>> thinking that it is a bug at some later stage. The text in the commit= =0A= >>>> message above is suitable.=0A= >>>>=0A= >>> Good suggestion! Will add it :)=0A= >>>=0A= >>>> John.=0A= >>>> --=0A= >=0A= =0A=