-
Feature Request
-
Resolution: Unresolved
-
Blocker
-
None
-
None
-
None
1. Proposed title of this feature request
Deterministically schedulable vhost threads
2. What is the nature and description of the request?
Currently, when a DPDK application requests vhost threads, these vhost threads run as children of kthreadd. They will be pinned to the entire cpuset of the calling application's container. However, they will not inherit the scheduling class, nor the CPU affinity of the calling application itself. And they will be running in the global PID namespace, meaning that the calling application cannot change pinning nor scheduling class of the vhost threads.
For context, see:
TL;DR: The upstream kernel "moved" vhost threads from being children of kthreadd to being children of the calling application. The calling application would be able to pin the vhost threads directly if it instantly tasksets the spawned vhost threads.
Caveats: However, the upstream change might break userspace and caused quite some fallout upstream. Red Hat's Jason Wang proposed adding a switch via a syscall so that applications can specifically request the old behavior (child of kthreadd) or the new behavior (child of calling process). Also, another problem that I see is: just inheriting the CPU affinity from the calling thread might not be good enough, we'd still lack an interface that allows the calling thread to immediately taskset the vhost threads, before they are spawned.
3. Why does the customer need this? (List the business requirements here)
Highly latency sensitive DPDK applications which use the vhost-net driver request vhost threads for packet processing on the kernel side, and these vhost threads currently interfere with the DPDK application's highly latency sensitive tasks. Customers need a way to be able to predictable pin vhost threads to specific CPUs
4. List any affected packages or components.