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
