gatekeeper
gatekeeper copied to clipboard
Gatekeeper cannot allocate 32GB of memory for the flow tables
When I tried to evaluate the performance of Gatekeeper with table size 2^29, Gatekeeper fails to run with the following error message: EAL: eal_memalloc_alloc_seg_bulk(): couldn't find suitable memseg_list
. After writing a minimum program that simply tries to allocate 32GB of memory, it fails with the same error. We have reported it to DPDK Bugzilla – Bug 608.
The first patch of pull request #538 largely increases the memory allocation capacity of Gatekeeper's version of DPDK. Thus, one will no longer need to work around this issue. Nevertheless, we are not closing this issue until a final solution makes upstream to DPDK.
Pull request #538 addressed this issue for our patched version of DPDK.
A long-term solution would be for DPDK to have a meson option for the maximum amount of hugepages memory that it can manage like it has options for the maximum number of Ethernet ports, lcores, and NUMA nodes. Thus, one could easily compile DPDK for any amount of hugepages needed.
Thanks to DPDK's commit 38689022f609a290645c7027084aee720c1fcf91, which DPDK merged on June 5th 2023, Gatekeeper may be able to use the functions rte_memzone_max_set()
and rte_memzone_max_get ()
to avoid patching DPDK to increase memory capacity.
This should be tested before closing this issue because the constants RTE_MAX_MEMSEG_PER_LIST
, RTE_MAX_MEM_MB_PER_LIST
, RTE_MAX_MEMSEG_PER_TYPE
, and RTE_MAX_MEM_MB_PER_TYPE
are still present in DPDK.
Thomas Monjalon suggested this solution during a Google Meet meeting on July 20th, 2023.
Testing rte_memzone_max_set()
shows no effect on the memory allocation limit because the constants RTE_MAX_MEMSEG_PER_LIST
, RTE_MAX_MEM_MB_PER_LIST
, RTE_MAX_MEMSEG_PER_TYPE
, and RTE_MAX_MEM_MB_PER_TYPE
are the root cause of the problem. The current workaround of increasing these constants is still necessary.