It is not obvious enough that control threads must run for DPDK to work correctly. Add a caveat to EAL documentation.
Signed-off-by: Stephen Hemminger <[email protected]> --- doc/guides/prog_guide/env_abstraction_layer.rst | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst index 0e1d044190..f36f9956c6 100644 --- a/doc/guides/prog_guide/env_abstraction_layer.rst +++ b/doc/guides/prog_guide/env_abstraction_layer.rst @@ -819,6 +819,20 @@ controlled with tools like taskset (Linux) or cpuset (FreeBSD), - with affinity restricted to 2-3, the Control Threads will end up on CPU 2 (main lcore, which is the default when no CPU is available). +DPDK uses control threads internally and those threads need to be able to run. +If all available CPUs are used as dataplane lcores, +control threads fall back to the main lcore and compete with a busy polling loop. +Ensure that at least a part of one CPU that is available for handling control events. + +The effects of control thread starvation are not always obvious, +and include delayed alarms, missed device and hotplug events, unresponsive telemetry, +and multi-process requests timing out so that secondary processes fail to start. + +.. warning:: + On Linux, if DPDK lcore threads run under a real-time scheduling policy + such as ``SCHED_FIFO`` or ``SCHED_RR`` on the same CPU as a control thread, + then kernel events will be missed. + .. _eal_known_issue_label: Known Issues -- 2.53.0
