Hi
I did contact TAC and got an explaination to as why it will not work on my small ESXi lab setup.
I have run alle versions from 8.0 up to 8.4.
As from 8.5 the system is checking NUMA nodes, this is what TAC wrote to me
The issue is seen when more than half the number of CPUs on ESXi are allocated to a VMM instance. For example, if the ESXI server has 12 CPUs and VMM instance is allocated >= 6 CPUs. This might be due to CPUs per socket configuration. On ESXi it was observed that when more than half the CPUs are allocated to a VMM instance then 2 NUMA nodes are assigned to the VMM. To override this set numa.autosize.vcpu.maxPerVirtualNode under VM advanced option to the number of CPUs allocated to the VMM. In this case only one NUMA node is assigned to the VMM and datapath wont crash.
To answer the question of why datapath crash is seen when 2 NUMA nodes are assigned. With 8.5.0.0 dpdk, hugetables are equally divided to both NUMA socket. What I observed was, even though 2 NUMA nodes are assigned, the physical_id for all CPUs under /proc/cpuinfo is assigned to 0. When dpdk tries to allocate memory on socket 1 it fails. I guess dpdk is not able to find the socket id 1. There seems to be a direct relation b/w socket to NUMA nodes.
This i guess is not an issue in larger ESXi installations, but my single server with sparse resources.
Roar