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 789062C4B for ; Mon, 14 Mar 2016 19:21:31 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 14 Mar 2016 11:21:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,336,1455004800"; d="scan'208";a="669416250" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by FMSMGA003.fm.intel.com with ESMTP; 14 Mar 2016 11:21:22 -0700 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by irsmsx105.ger.corp.intel.com (163.33.3.28) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 14 Mar 2016 18:21:21 +0000 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.87]) by irsmsx155.ger.corp.intel.com ([169.254.14.201]) with mapi id 14.03.0248.002; Mon, 14 Mar 2016 18:21:21 +0000 From: "Traynor, Kevin" To: Thomas Monjalon CC: "dev@dpdk.org" , "nakajima.yoshihiro@lab.ntt.co.jp" , "mst@redhat.com" , "p.fedin@samsung.com" , "ann.zhuangyanying@huawei.com" Thread-Topic: [dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create single mem-backed file Thread-Index: AQHRfgBfgkIEoX30xUOAg0mBVAOPZZ9ZP7oA Date: Mon, 14 Mar 2016 18:21:20 +0000 Message-ID: References: <1446748276-132087-1-git-send-email-jianfeng.tan@intel.com> <2329500.UVQ1bbgajc@xps13> <22781410.CoInzAJ6Km@xps13> In-Reply-To: <22781410.CoInzAJ6Km@xps13> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZjcwOTQ4OTItOWExNC00YzFlLTg3YTYtN2MzNmUwMDlkOTNiIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IjQ1VDBMMERKRnVpQlJYNEM3U21TWTlxbWQyeXlRSHhESTdKdVozajU1R3c9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2016 18:21:32 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > Sent: Monday, March 14, 2016 2:45 PM > To: Traynor, Kevin > Cc: dev@dpdk.org; nakajima.yoshihiro@lab.ntt.co.jp; mst@redhat.com; > p.fedin@samsung.com; ann.zhuangyanying@huawei.com > Subject: Re: [dpdk-dev] [PATCH v2 1/5] mem: add --single-file to create > single mem-backed file >=20 > 2016-03-14 13:53, Traynor, Kevin: > > From: Thomas Monjalon > > > 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: > > > > > Note that SINGLE_FILE_SEGMENTS is a nasty hack that only the IVSH= MEM > > > config > > > > > uses, getting rid of it (by replacing with a runtime switch) woul= d be > > > great. > > > > > > > > Can't agree more. > > > > > > +1 > > > > > > > > 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. > > > > > > The ivshmem config was not used for memnic which was using ivshmem on= ly > 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 clarify - is this suggesting the removal of the IVSHMEM library > itself, > > or just some of the config options? >=20 > I have no strong opinion about the library. > About the config options, yes they should be removed. Note that they are = not > documented, so we don't really know the motivation to have them. ok, thanks for clarifying. As there's no imminent plans to remove the libra= ry, I won't cross post.=20 >=20 > > The reason I ask is that although we don't currently use it in OVS with > DPDK, > > I've seen at least one person using it in conjunction with the ring > interface. > > There may be others, so I want to cross-post if there's a deprecation > discussion. >=20 > Thank you for sharing.