Hello!

quoted

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