From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 962548E5D for ; Tue, 12 Jan 2016 13:12:23 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 12 Jan 2016 04:12:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,557,1444719600"; d="scan'208";a="888841510" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.221.28]) ([10.237.221.28]) by orsmga002.jf.intel.com with ESMTP; 12 Jan 2016 04:12:21 -0800 To: Pavel Fedin References: <1446748276-132087-1-git-send-email-jianfeng.tan@intel.com> <1452426182-86851-1-git-send-email-jianfeng.tan@intel.com> <1452426182-86851-3-git-send-email-jianfeng.tan@intel.com> <5694C36D.2040006@intel.com> <00d501d14d20$930c8ae0$b925a0a0$@samsung.com> <5694D9E9.6060704@intel.com> <00de01d14d28$7c2eaf80$748c0e80$@samsung.com> <5694DE7C.4050206@intel.com> <00e301d14d2d$ad9cb350$08d619f0$@samsung.com> From: Sergio Gonzalez Monroy Message-ID: <5694EDA4.9030202@intel.com> Date: Tue, 12 Jan 2016 12:12:20 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <00e301d14d2d$ad9cb350$08d619f0$@samsung.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: nakajima.yoshihiro@lab.ntt.co.jp, "'Michael S. Tsirkin'" , dev@dpdk.org, ann.zhuangyanying@huawei.com Subject: Re: [dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info 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, 12 Jan 2016 12:12:24 -0000 On 12/01/2016 11:37, Pavel Fedin wrote: > Hello! > >> So are you suggesting to not introduce --single-file option but instead >> --shared-mem? >> AFAIK --single-file was trying to workaround the limitation of just >> being able to map 8 fds. > Heh, yes, you're right... Indeed, sorry, i was not patient enough, i see it uses hpi->hugedir instead of using /dev/shm... I was confused by the code path... It seemed that --single-file is an alias to --no-hugepages. > And the patch still changes mmap() mode to SHARED unconditionally, which is not good in terms of backwards compability (and this is explicitly noticed in the cover letter). I might be missing something obvious here but, aside from having memory SHARED which most DPDK apps using hugepages will have anyway, what is the backward compatibility issues that you see here? > > So, let's try to sort out... > a) By default we should still have MAP_PRIVATE > b) Let's say that we need --shared-mem in order to make it MAP_SHARED. This can be combined with --no-hugepages if necessary (this is what i tried to implement based on the old RFC). --share-mem would only have meaning with --no-huge, right? > c) Let's say that --single-file uses hugetlbfs but maps everything via single file. This still can be combined with --shared-mem. By default, when using hugepages all mappings are SHARED for multiprocess model. IMHO If you really want to have the ability to have private memory instead because you are not considering that model, then it might be more appropriate to have --private-mem or --no-shared-mem option instead. Sergio > wouldn't this be more clear, more straightforward and implication-free? > > And if we agree on that, we could now try to decrease number of options: > a) We could imply MAP_SHARED if cvio is used, because shared memory is mandatory in this case. > b) (c) above again raises a question: doesn't it make CONFIG_RTE_EAL_SIGLE_FILE_SEGMENTS obsolete? Or may be we could use that one instead of --single-file (however i'm not a fan of compile-time configuration like this)? > > Kind regards, > Pavel Fedin > Senior Engineer > Samsung Electronics Research center Russia > >