[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! > But in this case host gets this page size for total region size, therefore > qva_to_vva() fails. > I haven't worked with hugepages, but i guess that with real hugepages we > get one file per page, therefore page size == mapping size. With newly > introduced --single-file we now hav

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hi! On 1/12/2016 4:26 AM, Rich Lane wrote: > On Sun, Jan 10, 2016 at 3:43 AM, Jianfeng Tan > wrote: > > @@ -1157,6 +1180,20 @@ rte_eal_hugepage_init(void) > mcfg->memseg[0].len = internal_config.memory; > mcfg->memseg[

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! > I might be missing something obvious here but, aside from having memory > SHARED which most DPDK apps using hugepages will have anyway, what is > the backward compatibility issues that you see here? Heh, sorry once again for confusing. Indeed, with hugepages we always get MAP_SHARED.

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! > > .repeated depends on CONFIG_RTE_EAL_SIGLE_FILE_SEGMENTS. By the way, > > looks like it does > the same thing as you are trying to do with --single-file, but with > hugepages, doesn't it? I > see it's currently used by ivshmem (which is AFAIK very immature and > half-abandoned). >

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! > So are you suggesting to not introduce --single-file option but instead > --shared-mem? > AFAIK --single-file was trying to workaround the limitation of just > being able to map 8 fds. Heh, yes, you're right... Indeed, sorry, i was not patient enough, i see it uses hpi->hugedir instea

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! > Oh I get it and recognize the problem here. The actual problem lies in > the API rte_eal_get_backfile_info(). > backfiles[i].size = hugepage_files[i].size; > Should use statfs or hugepage_files[i].size * hugepage_files[i].repeated > to calculate the total size. .repeated depends on CON

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

On 12/01/2016 13:57, Pavel Fedin wrote: > Hello! > >> I might be missing something obvious here but, aside from having memory >> SHARED which most DPDK apps using hugepages will have anyway, what is >> the backward compatibility issues that you see here? > Heh, sorry once again for confusing. I

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! > > BTW, i'm still unhappy about ABI breakage here. I think we could easily > > add --shared-mem > option, which would simply change mapping mode to SHARED. So, we could use it > with both > hugepages (default) and plain mmap (with --no-hugepages). > > You mean, use "--no-hugepages --

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

On 12/01/2016 12:01, Pavel Fedin wrote: > Hello! > >>>.repeated depends on CONFIG_RTE_EAL_SIGLE_FILE_SEGMENTS. By the way, >>> looks like it does >> the same thing as you are trying to do with --single-file, but with >> hugepages, doesn't it? I >> see it's currently used by ivshmem (which i

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! >> Should this be "hugepage->size = internal_config.memory"? Otherwise the >> vhost-user >> memtable entry has a size of only 2MB. > I don't think so. See the definition: > 47 struct hugepage_file { > 48 void *orig_va; /**< virtual addr of first mmap() */ > 49 void

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

On 12/01/2016 11:37, Pavel Fedin wrote: > Hello! > >> So are you suggesting to not introduce --single-file option but instead >> --shared-mem? >> AFAIK --single-file was trying to workaround the limitation of just >> being able to map 8 fds. > Heh, yes, you're right... Indeed, sorry, i was not

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

On 12/01/2016 11:07, Sergio Gonzalez Monroy wrote: > Hi Pavel, > > On 12/01/2016 11:00, Pavel Fedin wrote: >> Hello! >> BTW, i'm still unhappy about ABI breakage here. I think we could easily add --shared-mem Could you elaborate a bit more on your concerns regarding ABI breakage ?

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

On 12/01/2016 11:22, Pavel Fedin wrote: > Hello! > >> Oh I get it and recognize the problem here. The actual problem lies in >> the API rte_eal_get_backfile_info(). >> backfiles[i].size = hugepage_files[i].size; >> Should use statfs or hugepage_files[i].size * hugepage_files[i].repeated >> to cal

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hi Pavel, On 12/01/2016 11:00, Pavel Fedin wrote: > Hello! > >>>BTW, i'm still unhappy about ABI breakage here. I think we could easily >>> add --shared-mem >> option, which would simply change mapping mode to SHARED. So, we could use >> it with both >> hugepages (default) and plain mmap (

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

Hello! > -Original Message- > From: Jianfeng Tan [mailto:jianfeng.tan at intel.com] > Sent: Sunday, January 10, 2016 2:43 PM > To: dev at dpdk.org > Cc: rich.lane at bigswitch.com; yuanhan.liu at linux.intel.com; mst at > redhat.com; > nakajima.yoshihiro at lab.ntt.co.jp; huawei.xie at i

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

On Sun, Jan 10, 2016 at 3:43 AM, Jianfeng Tan wrote: > @@ -1157,6 +1180,20 @@ rte_eal_hugepage_init(void) > mcfg->memseg[0].len = internal_config.memory; > mcfg->memseg[0].socket_id = socket_id; > > + hugepage = create_shared_memory(eal_hugepage_info_

[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info

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