> For the complete documentation index, see [llms.txt](https://mit-public-courses-cn-translatio.gitbook.io/mit6-s081/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://mit-public-courses-cn-translatio.gitbook.io/mit6-s081/lec21-networking-robert/21.9-ru-he-jie-jue-livelock.md).

# 21.9 如何解决Livelock

[论文](https://pdos.csail.mit.edu/6.828/2020/readings/mogul96usenix.pdf)作者对于Livelock提出了一种解决方法。这种解决方法的最直接结果就是，当packet的输入速率达到了5000pps，随着输入速率的增加，转发性能维持在5000pps。

![](/files/-MOsEcZS49o2HAkVFsMk)

曲线后半部分的水平是一种完美的non-livelock性能曲线。之所以是水平的，是因为受CPU的限制，最多只能处理5000pps的转发。

在这个解决方案中，还是存在处理packet的线程和中断处理程序。当网卡第一次触发中断时，会导致中断处理函数的运行。但是中断处理函数并不会从网卡拷贝packet，相应的，它会唤醒处理packet的线程，并且关闭网卡的中断，这样接下来就收不到任何中断了。处理packet的线程会有一个循环，在循环中它会检查并从网卡拉取几个packet，论文中我记得是最多拉取5个packet，之后再处理这些packet。所以现在处理packet的线程是从网卡读取packet，而不是从中断处理程序读取。如果网卡中没有等待处理的packet，那么处理线程会重新打开网卡中断，并进入sleep状态。因为最后打开了中断，当下一个packet到达时，中断处理程序会唤醒处理packet线程，线程会从sleep状态苏醒并继续处理packet。这就是论文介绍的解决Livelock的方法。

![](/files/-MOsHlbTFAdhy4F9lnj7)

这里的处理方式实际上是将中断模式（Interrupt Scheme）转变成了轮询模式（Polling Scheme）。在高负载的情况下，中断会被关闭，并且CPU会一直运行这里的循环中，不断读取packet并处理packet。因为中断被关闭了，CPU用来运行主线程的时间不会被中断占据。在低负载的情况下，中断会被打开，在收到packet之后，线程会被中断处理程序直接唤醒。

> 学生提问：这里的循环会检查所有的设备吗？还是只会检查产生中断的设备？
>
> Robert教授：这是个好问题，如果存在多个网卡，我并不知道这里的循环会怎么工作。一个非常合理的设计是，packet处理线程需要记录每个网卡是在中断模式还是在轮询模式，然后只对轮询模式的网卡。。。等一下，因为中断处理程序现在不从网卡读取packet，所以线程中的循环可以直接检查所有网卡，如果网卡中有待处理的packet，就读取几个packet并处理。如果所有的网卡都没有待处理的packet，主循环会打开所有网卡的中断，并进入sleep状态。之后，任何一个网卡的中断都会唤醒packet处理线程。
>
> 学生提问：当处理线程运行的时候，packet是如何进入到一个等待读取的队列中？我觉得网卡上只会有一个packet。
>
> Robert教授：最开始的时候，packet会在网卡自己的内存中按照队列形式缓存。而处理线程的主循环会询问每个网卡是否在自己的内存中有待处理的packet。如果有的话，主循环会在主机的RAM中申请缓存，再将packet数据从网卡中拷贝到RAM中的缓存，再处理packet。
>
> 学生提问：所以一次可以拷贝多个packet？
>
> Robert教授：是的，我认为论文中说的是一次拷贝5个packet。即使有100packet在网卡中等待处理，一次也只会读取5个，这样可以避免阻塞输出。
>
> 学生提问：但是这就要求提升网卡的内存容量了吧？
>
> Robert教授：Well，我不知道要多少内存容量。在Livelock曲线的转折点之前，都是靠中断来处理的。在转折点之前，如果网卡收到了一个packet，处理线程会立即被唤醒并读出packet。但是在转折点之后，处理线程就一直在轮询模式而不是中断模式。在转折点之后，肯定会有丢包，因为现在输入速率和输出速率之间是有差异的，而这个差异间的packet都被丢弃了。因为这些packet不论如何都会被丢弃，增加网卡的内存并不太能减少这里的丢包，所以不太确定网卡是否需要增加内存容量。在论文中，一次会读取最多5个packet，那么网卡必然需要存储5个packet的内存容量，但是更多的packet是否有好处就不太确定了。
>
> 网卡上的buffer大小，对于短暂的高pps有帮助，这样可以保存好packet等处理线程来读取它们。但是我们这里并没有讨论短暂的overload，我们讨论的是持续的overload。所以增加网卡的buffer，并不是很有用。
>
> 学生提问：当网卡中断被关闭了，网卡还能在自己的buffer上加入新的packet吗？
>
> Robert教授：可以的。网卡是自治的，不论中断是打开还是关闭，只要有一个packet到达了网卡，网卡都会将packet加入到自己的缓存队列中。当然不同的网卡设计可能非常不一样，但是在论文中网卡不会调用DMA，不会主动访问主机内存。如果网卡上内存都用光了，packet会被丢弃。所以，在这里的设计中，丢包发生在网卡内部。在一个overload的场景下，网卡中的队列总是满的，当再收到一个packet时，网卡会直接丢包，这样就不会浪费CPU时间。网卡可以在不消耗CPU时间的前提下直接丢包，是避免Livelock的直接原因。
>
> 学生提问：有没有这种可能，CPU从网卡读取packet，但是处理线程内部的队列满了？
>
> Robert教授：当然。在其他地方肯定也有瓶颈，例如对于收到的packet，需要交给监听了socket的应用程序去处理，如果应用程序并没有以足够快的速度读取packet，相应的socket buffer会满，那么packet会在处理线程中丢包，而这也可能导致Livelock。
>
> Livelock发生的根本原因是我们浪费时间处理了一些最终会被丢弃的packet，这里的处理是徒劳。另一种发生Livelock的可能是，当负载增加时，我们可能会消耗100%的CPU时间在packet处理线程上，而留给应用程序的CPU时间为0，这时还是会发生Livelock。论文在第六节中有相应的介绍，如果一个packet将要被传输给本地的应用程序，网络线程会查看应用程序的socket buffer，如果socket buffer过满的话，网络线程会停止从网卡读取packet，直到socket buffer变小。这意味着网络线程会停止运行，并给应用程序机会运行并处理packet，所以如果你不够小心的话，你可能会在任何阶段都经历类似Livelock的问题。