From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2 1/5] mem: add --single-file to create single mem-backed file Date: Mon, 14 Mar 2016 15:45:25 +0100 Message-ID: <22781410.CoInzAJ6Km@xps13> References: <1446748276-132087-1-git-send-email-jianfeng.tan@intel.com> <2329500.UVQ1bbgajc@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, "nakajima.yoshihiro@lab.ntt.co.jp" , "mst@redhat.com" , "p.fedin@samsung.com" , "ann.zhuangyanying@huawei.com" To: "Traynor, Kevin" Return-path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 293ED530F for ; Mon, 14 Mar 2016 15:46:50 +0100 (CET) Received: by mail-wm0-f49.google.com with SMTP id l68so111075439wml.0 for ; Mon, 14 Mar 2016 07:46:50 -0700 (PDT) In-Reply-To: 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" 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 IVSHMEM > > config > > > > uses, getting rid of it (by replacing with a runtime switch) would 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 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 clarify - is this suggesting the removal of the IVSHMEM library itself, > or just some of the config options? 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. > 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. Thank you for sharing.