From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id EB5542C67 for ; Tue, 8 Mar 2016 03:51:30 +0100 (CET) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga103.jf.intel.com with ESMTP; 07 Mar 2016 18:51:29 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,554,1449561600"; d="scan'208";a="904495486" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.66.49]) by orsmga001.jf.intel.com with ESMTP; 07 Mar 2016 18:51:26 -0800 Date: Tue, 8 Mar 2016 10:53:46 +0800 From: Yuanhan Liu To: "Tan, Jianfeng" Message-ID: <20160308025346.GK14300@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-3-git-send-email-jianfeng.tan@intel.com> <20160307132238.GI14300@yliu-dev.sh.intel.com> <56DE396E.7050708@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56DE396E.7050708@intel.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 2/5] mem: add API to obtain 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, 08 Mar 2016 02:51:31 -0000 On Tue, Mar 08, 2016 at 10:31:10AM +0800, Tan, Jianfeng wrote: > > > On 3/7/2016 9:22 PM, Yuanhan Liu wrote: > >On Fri, Feb 05, 2016 at 07:20:25PM +0800, Jianfeng Tan wrote: > >>A new API named rte_eal_get_backfile_info() and a new data > >>struct back_file is added to obstain information of memory- > >>backed file info. > >I would normally suggest to try hard to find some solution else, instead > >of introducing yet another new API, espeically when you just came up with > >one user only. > > Actually, Tetsuya's qtest patchset will make it two. Well, it's actually a same story. So, still one user to me. > > > >>Signed-off-by: Huawei Xie > >>Signed-off-by: Jianfeng Tan > >>--- > >> lib/librte_eal/common/include/rte_memory.h | 16 ++++++++++++ > >> lib/librte_eal/linuxapp/eal/eal_memory.c | 40 +++++++++++++++++++++++++++++- > >> 2 files changed, 55 insertions(+), 1 deletion(-) > >> > >>diff --git a/lib/librte_eal/common/include/rte_memory.h b/lib/librte_eal/common/include/rte_memory.h > >>index 587a25d..b09397e 100644 > >>--- a/lib/librte_eal/common/include/rte_memory.h > >>+++ b/lib/librte_eal/common/include/rte_memory.h > >>@@ -109,6 +109,22 @@ struct rte_memseg { > >> } __rte_packed; > >> /** > >>+ * This struct is used to store information about memory-backed file that > >>+ * we mapped in memory initialization. > >>+ */ > >>+struct back_file { > >>+ void *addr; /**< virtual addr */ > >>+ size_t size; /**< the page size */ > >>+ char filepath[PATH_MAX]; /**< path to backing file on filesystem */ > >>+}; > >So, that's all the info you'd like to get. I'm thinking you may don't > >need another new API to retrieve them at all: > > > >Say, you can get the filepath and fd from /proc/self/fd (by filtering it > >with "rtemap_"): > > > > $ ls /proc/3487/fd -l > > total 0 > > lrwx------ 1 root root 64 Mar 7 20:37 0 -> /dev/pts/2 > > lrwx------ 1 root root 64 Mar 7 20:37 1 -> /dev/pts/2 > > lrwx------ 1 root root 64 Mar 7 20:37 2 -> /dev/pts/2 > > lrwx------ 1 root root 64 Mar 7 20:37 3 -> /run/.rte_config > > lr-x------ 1 root root 64 Mar 7 20:37 4 -> /dev/hugepages > > lr-x------ 1 root root 64 Mar 7 20:37 5 -> /mnt > >==> lrwx------ 1 root root 64 Mar 7 20:37 6 -> /dev/hugepages/rtemap_0 > > I guess this rtemap_xxx has been closed after memory initialization and > cannot be obtained from /proc/xxx/fd. I believe /proc/xxx/maps is what you > want to say. Yes, I forgot to mention that you need keep that file open. So, you just need one line or two to not close that file in this case. > > > > > > >Which could also save you an extra "open" at caller side for that > >file as well. > > Same reason, we cannot save extra "open". We could, if we keep the file open. > > > >And you can get the virtual addr and size from /proc/self/maps: > > > > $ grep rtemap_ /proc/3487/maps > > 7fff40000000-7fffc0000000 rw-s 00000000 00:22 21082 /dev/hugepages/rtemap_0 > > > > > >Will that work for you? > > Yes, from function's side, it works for me. But it needs some string > processing. What's wrong of the string processing? I have seen many string processings in DPDK code, even in rte_memory.c. > Another way is to just exposed an global variable pointing to > the address of /run/.rte_config, so that callers extract needed information > by themselves using "struct hugepage_file". How do you think? That doens't seem elegant to me. --yliu