[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