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

Tan, Jianfeng jianfeng.tan at intel.com
Tue Mar 8 03:31:10 CET 2016



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 <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.

>
>
> 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



More information about the dev mailing list