From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <jianfeng.tan@intel.com>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
by dpdk.org (Postfix) with ESMTP id 7890B559C
for <dev@dpdk.org>; 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" <jianfeng.tan@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "dev@dpdk.org"
<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: <ED26CBA2FAD1BF48A8719AEF02201E3663A8C8@SHSMSX152.ccr.corp.intel.com>
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>
<ED26CBA2FAD1BF48A8719AEF02201E36634DD6@SHSMSX152.ccr.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" <nakajima.yoshihiro@lab.ntt.co.jp>,
"zhbzg@huawei.com" <zhbzg@huawei.com>, "mst@redhat.com" <mst@redhat.com>,
"gaoxiaoqiu@huawei.com" <gaoxiaoqiu@huawei.com>,
"oscar.zhangbo@huawei.com" <oscar.zhangbo@huawei.com>,
"ann.zhuangyanying@huawei.com" <ann.zhuangyanying@huawei.com>,
"zhoujingbin@huawei.com" <zhoujingbin@huawei.com>,
"guohongzhen@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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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