Re: [dpdk-dev] [PATCH v2 9/9] mem: support in-memory mode

[Thomas Monjalon <thomas@monjalon.net>]

There is a compilation error:

../lib/librte_eal/linuxapp/eal/eal_memalloc.c: In function ‘alloc_seg’:
../lib/librte_eal/linuxapp/eal/eal_memalloc.c:619:3: error:
‘map_offset’ may be used uninitialized in this function


13/07/2018 12:27, Anatoly Burakov:
> Implement the final piece of the in-memory mode puzzle - enable running
> DPDK entirely in memory, without creating any files.
> 
> To do it, use mmap with MAP_HUGETLB and size flags to enable DPDK to work
> without hugetlbfs mountpoints. In order to enable this, a few things needed
> to be changed.
> 
> First of all, we need to allow empty hugetlbfs mountpoints in
> hugepage_info, and handle them correctly (by not trying to create any
> files and lock any directories).
> 
> Next, we need to reorder the mapping sequence, because the page is not
> really allocated until the page fault, and we cannot get its IOVA
> address before we trigger the page fault.
> 
> Finally, decide at compile time whether we are going to be supporting
> anonymous hugepages or not, because we cannot check for it at runtime.
> 
> Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
> ---
> 
> Notes:
>     RFC->v1:
>     - Drop memfd and instead use mmap() with MAP_HUGETLB. This will drop the
>       kernel requirements down to 3.8, and does not impose any restrictions
>       glibc (as far as i known).
>     
>       Unfortunately, there's a bit of an issue with this approach, because
>       mmap() is stupid and will happily ignore unsupported arguments. This
>       means that if the binary were to be compiled on a 3.8+ kernel but run
>       on a pre-3.8 kernel (such as currently supported minimum of 3.2), then
>       most likely the memory would be allocated using regular pages, causing
>       unthinkable performance degradation. No solution to this problem is
>       currently known to me.