[dpdk-dev] [PATCH 2/4] mem: add API to obstain memory-backed file info
Pavel Fedin
p.fedin at samsung.com
Tue Jan 12 11:04:04 CET 2016
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 *final_va; /**< virtual addr of 2nd mmap() */
> 50 uint64_t physaddr; /**< physical addr */
> 51 size_t size; /**< the page size */
> 52 int socket_id; /**< NUMA socket ID */
> 53 int file_id; /**< the '%d' in HUGEFILE_FMT */
> 54 int memseg_id; /**< the memory segment to which page belongs */
> 55 #ifdef RTE_EAL_SINGLE_FILE_SEGMENTS
> 56 int repeated; /**< number of times the page size is repeated */
> 57 #endif
> 58 char filepath[MAX_HUGEPAGE_PATH]; /**< path to backing file on filesystem */
> 59 };
> size stands for the page size instead of total size.
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 have something that pretends to be a single "uber-huge-page", so we need to specify total size of the mapping here.
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).
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia
More information about the dev
mailing list