From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id C87C3275D for ; Tue, 8 Mar 2016 10:02:26 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP; 08 Mar 2016 01:02:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,556,1449561600"; d="scan'208";a="665695501" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49]) by FMSMGA003.fm.intel.com with ESMTP; 08 Mar 2016 01:02:25 -0800 Date: Tue, 8 Mar 2016 17:04:45 +0800 From: Yuanhan Liu To: Panu Matilainen Message-ID: <20160308090445.GN14300@yliu-dev.sh.intel.com> References: <1446748276-132087-1-git-send-email-jianfeng.tan@intel.com> <1454671228-33284-1-git-send-email-jianfeng.tan@intel.com> <1454671228-33284-2-git-send-email-jianfeng.tan@intel.com> <20160307131322.GH14300@yliu-dev.sh.intel.com> <56DE921A.4060203@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56DE921A.4060203@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: nakajima.yoshihiro@lab.ntt.co.jp, mst@redhat.com, dev@dpdk.org, 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 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: Tue, 08 Mar 2016 09:02:27 -0000 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) would be great. Can't agree more. 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.