[dpdk-dev] [PATCH v2 2/5] mem: add API to obtain memory-backed file info

Yuanhan Liu yuanhan.liu at linux.intel.com
Tue Mar 8 03:53:46 CET 2016


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 <huawei.xie at intel.com>
> >>Signed-off-by: Jianfeng Tan <jianfeng.tan at intel.com>
> >>---
> >>  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


More information about the dev mailing list