From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 7890B559C for ; Mon, 9 Nov 2015 15:13:54 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP; 09 Nov 2015 06:13:53 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,266,1444719600"; d="scan'208";a="681411673" Received: from fmsmsx106.amr.corp.intel.com ([10.18.124.204]) by orsmga003.jf.intel.com with ESMTP; 09 Nov 2015 06:13:43 -0800 Received: from FMSMSX110.amr.corp.intel.com (10.18.116.10) by FMSMSX106.amr.corp.intel.com (10.18.124.204) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 9 Nov 2015 06:13:43 -0800 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by fmsmsx110.amr.corp.intel.com (10.18.116.10) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 9 Nov 2015 06:13:42 -0800 Received: from shsmsx152.ccr.corp.intel.com ([169.254.6.193]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.223]) with mapi id 14.03.0248.002; Mon, 9 Nov 2015 22:13:41 +0800 From: "Tan, Jianfeng" To: "Ananyev, Konstantin" , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [RFC 4/5] virtio/container: adjust memory initialization process Thread-Index: AQHRGK9CZ9YhP3BPnkOPJZjw/l2eSJ6R9RiggAE5lYCAAI7YMA== Date: Mon, 9 Nov 2015 14:13:40 +0000 Message-ID: References: <1446748276-132087-1-git-send-email-jianfeng.tan@intel.com> <1446748276-132087-5-git-send-email-jianfeng.tan@intel.com> <2601191342CEEE43887BDE71AB97725836ABD716@IRSMSX153.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725836AC618B@irsmsx105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725836AC618B@irsmsx105.ger.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 Cc: "nakajima.yoshihiro@lab.ntt.co.jp" , "zhbzg@huawei.com" , "mst@redhat.com" , "gaoxiaoqiu@huawei.com" , "oscar.zhangbo@huawei.com" , "ann.zhuangyanying@huawei.com" , "zhoujingbin@huawei.com" , "guohongzhen@huawei.com" Subject: Re: [dpdk-dev] [RFC 4/5] virtio/container: adjust memory initialization process 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: Mon, 09 Nov 2015 14:13:55 -0000 > ...... > > > > +int > > > > +rte_memseg_info_get(int index, int *pfd, uint64_t *psize, void > > > > +**paddr) { > > > > + struct rte_mem_config *mcfg; > > > > + mcfg =3D rte_eal_get_configuration()->mem_config; > > > > + > > > > + *pfd =3D mcfg->memseg[index].fd; > > > > + *psize =3D (uint64_t)mcfg->memseg[index].len; > > > > + *paddr =3D (void *)(uint64_t)mcfg->memseg[index].addr; > > > > + return 0; > > > > +} > > > > > > Wonder who will use that function? > > > Can't see any references to that function in that patch or next. > > > > This function is used in 1/5, when virtio front end needs to send > VHOST_USER_SET_MEM_TABLE to back end. >=20 > Ok, but hen this function should be defined in the patch *before* it is u= sed, > not after. > Another thing: probably better to create a struct for all memseg paramete= rs > you want to retrieve, and pass it to the function, instead of several poi= nters. Very good suggestion! I'll fix it in next version. > > > > + addr =3D rte_eal_shm_create(&fd); > > > > > > Why do you remove ability to map(dev/zero) here? > > > Probably not everyone plan to use --no-hugepages only inside containe= rs. > > > > From my understanding, mmap here is just to allocate some memory, > > which is initialized to be all zero. I cannot understand what's the > relationship with /dev/zero. >=20 > I used it here as a synonym for mmap(, ..., MAP_ANONYMOUS,...). >=20 > rte_eal_shm_create() can do the original function, plus it generates a f= d to > point to this chunk of > > memory. This fd is indispensable in vhost protocol when > VHOST_USER_SET_MEM_TABLE using sendmsg(). >=20 >=20 > My question was: > Right now for --no-hugepages it allocates a chunk of memory that is not > backed-up by any file and is private to the process: >=20 > addr =3D mmap(NULL, internal_config.memory, PROT_READ | PROT_WRITE, > MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); >=20 > You changed it to shared memory region allocation: >=20 > fd =3D shm_open(filepath, O_CREAT | O_RDWR, S_IRUSR | S_IWUSR); addr =3D > mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); >=20 > I understand that you need it for your containers stuff - but I suppose y= ou > have to add new functionality without breaking existing one> There could = be > other users of --no-hugepages and they probably want existing behaviour. > Konstantin Thank you for patient analysis and I agree with you. I should have not brea= k compatibility with existing applications. I'd like to redesign this in next= version. Maybe a new cmd option is necessary here. Jianfeng ..... > > > > -- > > > > 2.1.4