From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 5C6A1590C for ; Thu, 19 Nov 2015 04:54:37 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga101.fm.intel.com with ESMTP; 18 Nov 2015 19:54:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,316,1444719600"; d="scan'208";a="854240837" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga002.jf.intel.com with ESMTP; 18 Nov 2015 19:54:36 -0800 Received: from fmsmsx124.amr.corp.intel.com (10.18.125.39) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 18 Nov 2015 19:54:35 -0800 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx124.amr.corp.intel.com (10.18.125.39) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 18 Nov 2015 19:54:35 -0800 Received: from shsmsx152.ccr.corp.intel.com ([169.254.6.193]) by shsmsx102.ccr.corp.intel.com ([169.254.2.42]) with mapi id 14.03.0248.002; Thu, 19 Nov 2015 11:54:33 +0800 From: "Wang, Zhihong" To: "Xie, Huawei" , "Mcnamara, John" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessary hugepage zero-filling Thread-Index: AQHRIfnBQqkEhqWt1Uy9EiEXxdbH7J6itOaA Date: Thu, 19 Nov 2015 03:54:32 +0000 Message-ID: <8F6C2BD409508844A0EFC19955BE0941834AFE@SHSMSX152.ccr.corp.intel.com> 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> In-Reply-To: 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 03:54:37 -0000 > -----Original Message----- > From: Xie, Huawei > Sent: Wednesday, November 18, 2015 8:08 PM > To: Wang, Zhihong ; Mcnamara, John > ; dev@dpdk.org > Subject: Re: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove unnecessar= y > hugepage zero-filling >=20 > On 11/18/2015 6:45 PM, Wang, Zhihong wrote: > >> -----Original Message----- > >> From: Mcnamara, John > >> Sent: Wednesday, November 18, 2015 6:40 PM > >> To: Wang, Zhihong ; dev@dpdk.org > >> Subject: RE: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove > >> unnecessary hugepage zero-filling > >> > >> > >> > >>> -----Original Message----- > >>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Zhihong Wang > >>> Sent: Wednesday, November 18, 2015 3:27 AM > >>> To: dev@dpdk.org > >>> Subject: [dpdk-dev] [RFC PATCH 2/2] lib/librte_eal: Remove > >>> unnecessary hugepage zero-filling > >>> > >>> The kernel fills new allocated (huge) pages with zeros. > >>> DPDK just has to touch the pages to trigger the allocation. > I think we shouldn't reply on the assumption that kernel has zeroed the m= emory. I understand the concern. In my opinion application shouldn't assume malloced memory to be zero-fille= d. So it should be okay for DPDK even if the kernel doesn't zero the page a= t all. I agree that we should check if any code accidentally make that assumption.= Currently there's rte_pktmbuf_init() for packet mbuf initialization. /Zhihong > Kernel zeroes the memory mostly to avoid information leakage.It could als= o > achieve this by setting each bit to 1. > What we indeed need to check is later DPDK initialization code doesn't as= sume > the memory has been zeroed. Otherwise zero only that part of the memory. > Does this makes sense? >=20 > >>> ... > >>> if (orig) { > >>> hugepg_tbl[i].orig_va =3D virtaddr; > >>> - memset(virtaddr, 0, hugepage_sz); > >>> + memset(virtaddr, 0, 8); > >>> } > >> Probably worth adding a one or two line comment here to avoid someone > >> thinking that it is a bug at some later stage. The text in the commit > >> message above is suitable. > >> > > Good suggestion! Will add it :) > > > >> John. > >> -- > >