[dpdk-dev] questions about Windows basic memory management patch

[Dmitry Kozlyuk]

Hi,

> In the "eal/windows: fix rte_page_sizes with Clang on Windows" (http://patches.dpdk.org/patch/67390/) patch I didn't understand the work around that you did and what the problem was.

Clang on Windows always uses uint32_t as an underlying type for enums. As a
consequence, rte_hugepage_sizes cannot contain elements from 4GB onwards,
because they will be clamped to 0, resulting in the following error:

[17/41] Compiling C object lib/76b5a35@@rte_eal at sta/librte_eal_common_malloc_heap.c.obj.
FAILED: lib/76b5a35@@rte_eal at sta/librte_eal_common_malloc_heap.c.obj
clang @lib/76b5a35@@rte_eal at sta/librte_eal_common_malloc_heap.c.obj.rsp
../../../lib/librte_eal/common/malloc_heap.c:69:7: error: duplicate case value: 'RTE_PGSIZE_4G' and 'RTE_PGSIZE_16G' both equal '0'
        case RTE_PGSIZE_16G:
             ^
../../../lib/librte_eal/common/malloc_heap.c:66:7: note: previous case defined here
        case RTE_PGSIZE_4G:
             ^
1 error generated.

Maybe there's a better way to explain it in comments and commit message?

After I moved RTE_PGSIZE_4G and RTE_PGSIZE_16G outside of the enum, I had to
add `-fno-strict-enum` so that these values could be passed to where
rte_page_sizes is expected.


> Regarding rte_mp functions I see you implemented a stub, i.e. empty functions. I don't know why it is needed.

They're called from common EAL memory management routines.


> Just to make sure, does the rte_mem_map function that you implemented replaces Linux's mmap function ?

Yes. DPDK libraries have a few places they need memory-mapped files or
anonymous mappings, so I exported it (librte_mempool being the closest one,
libre_bpf also comes to my mind).


> Lastly, in the patch you implemented functions that were common for Linux and FreeBSD and in order to use them in Windows (e.g. eal_file_truncate that replaced ftruncate) and you got a duplicate code for Linux and FreeBSD, how can we solve this duplication ?

In v2 I'm going to create lib/librte_eal/posix subdirectory and move such
code there. I expect more code to end up there eventually, for example,
dynamic library loading. This possibility was among motivations for EAL
directory split.

There're another duplication that worries me: copy & paste from Linux EAL in
eal_malloc.c and eal_memory.c initialization. However, it this can't be
helped, I'd rather leave it be for now and reconsider it when implementing
advanced memory management.

-- 
Dmitry Kozlyuk