From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Tan, Jianfeng" Subject: Re: [RFC 4/5] virtio/container: adjust memory initialization process 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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" To: "Ananyev, Konstantin" , "dev@dpdk.org" 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) In-Reply-To: <2601191342CEEE43887BDE71AB97725836AC618B@irsmsx105.ger.corp.intel.com> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" > ...... > > > > +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