From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <anatoly.burakov@intel.com>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by dpdk.org (Postfix) with ESMTP id 75F7B2C6B
 for <dev@dpdk.org>; Tue,  8 Mar 2016 11:57:27 +0100 (CET)
Received: from orsmga001.jf.intel.com ([10.7.209.18])
 by fmsmga102.fm.intel.com with ESMTP; 08 Mar 2016 02:57:26 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.22,556,1449561600"; d="scan'208";a="904829152"
Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157])
 by orsmga001.jf.intel.com with ESMTP; 08 Mar 2016 02:57:24 -0800
Received: from irsmsx109.ger.corp.intel.com ([169.254.13.174]) by
 IRSMSX103.ger.corp.intel.com ([169.254.3.239]) with mapi id 14.03.0248.002;
 Tue, 8 Mar 2016 10:57:23 +0000
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>, "dev@dpdk.org" <dev@dpdk.org>
Thread-Topic: [dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create
 single mem-backed file
Thread-Index: AQHReHLkmRmkp8nnIUq5/HkypMaFwp9PPfUAgAAEQ4CAABf5gIAABp8A
Date: Tue, 8 Mar 2016 10:57:22 +0000
Message-ID: <C6ECDF3AB251BE4894318F4E45123697820D43A7@IRSMSX109.ger.corp.intel.com>
References: <1446748276-132087-1-git-send-email-jianfeng.tan@intel.com>
 <56DE921A.4060203@redhat.com> <20160308090445.GN14300@yliu-dev.sh.intel.com>
 <2329500.UVQ1bbgajc@xps13>
In-Reply-To: <2329500.UVQ1bbgajc@xps13>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ctpclassification: CTP_IC
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTQ4YTBhZGQtYTZiYi00OTkxLThjMTMtYTgwZjYzNGY0NzU1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlJpbFZTSGpuMTlvV3hVK0x4bkdZYlpWYk8ycjFwT1g1ZTdDT0FWU3FzVmc9In0=
x-originating-ip: [163.33.239.180]
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>,
 "mst@redhat.com" <mst@redhat.com>, "p.fedin@samsung.com" <p.fedin@samsung.com>,
 "ann.zhuangyanying@huawei.com" <ann.zhuangyanying@huawei.com>
Subject: Re: [dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create
 single mem-backed file
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: Tue, 08 Mar 2016 10:57:27 -0000

Hi Thomas,

> 2016-03-08 17:04, Yuanhan Liu:
> > On Tue, Mar 08, 2016 at 10:49:30AM +0200, Panu Matilainen wrote:
> > > On 03/07/2016 03:13 PM, Yuanhan Liu wrote:
> > > >To me, maybe you could base the SINGLE_FILE_SEGMENTS option, and
> > > >add another option, say --no-sort (I confess this name sucks, but
> > > >you get my point). With that, we could make sure to create as least
> > > >huge page files as possible, to fit your case.
> > >
> > > Note that SINGLE_FILE_SEGMENTS is a nasty hack that only the
> IVSHMEM
> > > config uses, getting rid of it (by replacing with a runtime switch) w=
ould be
> great.
> >
> > Can't agree more.
>=20
> +1
>=20
> > BTW, FYI, Jianfeng and I had a private talk, and we came to agree that
> > it might be better to handle it outside the normal huge page init
> > stage, just like this patch does, but adding the support of multiple
> > huge page sizes. Let's not add more messy code there.
> >
> > 	--yliu
> >
> > > OTOH IVSHMEM itself seems to have fallen out of the fashion since
> > > the memnic driver is unmaintained and broken since dpdk 2.0...
> > > CC'ing the IVSHMEM maintainer in case he has thoughts on this.
>=20
> The ivshmem config was not used for memnic which was using ivshmem only
> for data path.
> CONFIG_RTE_LIBRTE_IVSHMEM and
> CONFIG_RTE_EAL_SINGLE_FILE_SEGMENTS are more about full memory
> sharing.
> I have the feeling it could be dropped.
> It there are some users, I'd like to see a justification and a rework to =
remove
> these build options.

Just to add my opinion to it - if there are no users for both of these, I'd=
 like for those to be removed as well. Less maintenance is always better th=
an more maintenance, especially for things that no one uses :)

Thanks,
Anatoly