我在改进虚拟机（VM）的TCP / UDP性能方面做了一些研究时遇到了一些问题，如果有人能给我一些帮助或建议来解决我的问题，我将非常感激。
RPS＆amp; RFS在物理机器上运行良好，但有时它们可能无法在VM上运行。例如，RFS旨在将IRQ发送到运行相应接收过程的CPU。但是，当多个vCPU共享一个物理CPU（pCPU）时，每个VM的虚拟CPU（vCPU）不能始终在线（这里我们可以简单地假设vCPU调度是循环的）。因此，即使目标用户级进程正在其上运行，将IRQ发送到脱机vCPU也没有意义。从理论上讲，将NIC IRQ发送到正在运行的VM的vCPU将缩小NIC IRQ处理延迟并提高TCP / UDP性能。因此，我分配了一个虚拟协处理器（co-vCPU），它几乎总是在线连接到每个VM，并将VM的NIC IRQ固定到此co-vCPU。从VM中的Guest OS的角度来看，用户进程（例如iperf）在一个核上运行，eth0的IRQ上下文在另一个核上运行。在我的实验中，它适用于UDP，但不适用于TCP。
我怀疑这是由于进程上下文和IRQ上下文之间的同步。因为当我在linux中读取TCP层的一些源代码时，我发现IRQ上下文（例如net / ipv4 / tcp_ipv4.c中的tcp_v4_rcv（））和用户上下文（例如net / ipv4 / tcp.c中的tcp_recvmsg（））当他们访问内核中的缓冲区（receive_queue，backlog_queue，prequeue）时调用lock_sock（）/ unlock_sock（）。因此，有时IRQ无法访问由运行用户级别接收进程（iperf服务器）的另一个vCPU锁定的接收缓冲区，并且持有该锁定的此vCPU已由VM监视器（VMM）或虚拟机监控程序进行了调度。
我不确定我是否清楚地描述了我的问题。无论如何，欢迎任何建议。