From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id CE9222C4A for ; Tue, 8 Mar 2016 03:31:15 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 07 Mar 2016 18:31:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,554,1449561600"; d="scan'208";a="918996081" Received: from shwdeisgchi083.ccr.corp.intel.com (HELO [10.239.67.193]) ([10.239.67.193]) by fmsmga001.fm.intel.com with ESMTP; 07 Mar 2016 18:31:11 -0800 To: Yuanhan Liu 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> From: "Tan, Jianfeng" Message-ID: <56DE396E.7050708@intel.com> Date: Tue, 8 Mar 2016 10:31:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160307132238.GI14300@yliu-dev.sh.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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:31:16 -0000 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. > >> 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. > > > Which could also save you an extra "open" at caller side for that > file as well. Same reason, we cannot save extra "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. 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? Thanks, Jianfeng > > --yliu