Illustrated Guide to Monitoring and Tuning the Linux Networking Stack: Receiving Data

本文主要是介绍Illustrated Guide to Monitoring and Tuning the Linux Networking Stack: Receiving Data，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

太长不读（TL; DR）

这篇文章用一系列图表扩展了以前的博客文章Monitoring and Tuning the Linux Networking Stack: Receiving Data，旨在帮助读者形成一个更清晰的视野来了解Linux网络协议栈是如何工作的

在监控或调优 Linux 网络协议栈试没有捷径可走。如果你希望调整或优化每个组件及其相互作用，你就必须努力充分了解它们。也就是说，以前博客文章的长度可能使读者难以概念化各种组件如何相互作用。希望这个博客文章将有助于澄清这一点了。

Getting started

这些图表旨在概述 Linux 网络协议栈的工作原理，因此，许多细节被排除在外。为了获得完整的描述，我们鼓励读者阅读我们的博客文章 Monitoring and Tuning the Linux Networking Stack: Receiving Data，详细涵盖网络协议栈的各个方面。这些图示的目的是帮助读者形成一个思维的模型，在更高层面了解内核中的某些系统是如何相互作用的。

首先，让我们先看看一些重要的初始设置，这是理解数据包处理之前所必须的。

Initial setup

设备有许多方法可以提醒cpu的其余部分，某些工作已准备就绪。在网络设备的情况下，NIC 通常会触发 IRQ 中断信号来表示数据包已到达并准备等待处理。当 该IRQ 中断处理被Linux 内核执行时，它会以非常非常高的优先级运行，并且阻止触发其他中断（ IRQ）。因此，设备驱动程序中的 IRQ 中断处理程序必须尽快执行，并将耗时的操作推迟到中断下半部执行。这就是 “softIRQ”存在的原因。

Linux 内核中的"softIRQ"组件是一个内核用于处理设备驱动程序中断（IRQ）上下文之外工作的组件，在网络设备的情况下，软中断系统负责处理即将传入的数据包。软中断是在在内核早期的启动过程中初始化的。

上图对应于softIRQ section of our network blog post，并显示了软中断系统及其在每个CPU内核线程的初始化。

软中断系统的初始化如下：

• 1、内核软中断线程（每个CPU一个）由kernel/softirq.c中的spawn_ksoftirqd调用来自kernel/smpboot.c定义的smpboot_register_percpu_thread创建。如代码所见，run_ksoftirqd的函数被定义为thread_fn，即将在smpboot_thread_fn函数中循环调用。

  static struct smp_hotplug_thread softirq_threads = {                                 .store          = &ksoftirqd,.thread_should_run  = ksoftirqd_should_run,.thread_fn      = run_ksoftirqd,.thread_comm        = "ksoftirqd/%u",
  };                        static __init int spawn_ksoftirqd(void)
  {                         register_cpu_notifier(&cpu_nfb);BUG_ON(smpboot_register_percpu_thread(&softirq_threads));return 0;             
  }                      
  early_initcall(spawn_ksoftirqd);
  

• 2、ksoftirqd 线程开始循环调用run_ksoftirqd功能进行处理。

• 3、接下来，为每个 CPU 创建一个softnet_data结构。这个结构体是处理网络数据的重要数据结构。我们会在poll_list中再次看到。poll_list的NAPI 轮询操作结构是通过设备驱动程序调用napi_schedule或其他 NAPI API 调度的。

• 4、net_dev_init 然后通过调用 open_softirq 向 softirq 系统注册NET_RX_SOFTIRQ软中断。注册的处理函数是net_rx_action。 这就是 softirq 内核线程将执行并用来处理数据包的功能。

Data arrives

Data arrives from the network!

当网络数据到达 NIC 网卡时，网卡会使用DMA将数据包写入RAM。在 igb 网络驱动程序中，在 RAM 中分配了一个环形缓冲区用来指向接收到的数据包。需要注意的是，某些 NICs 是“多队列”NICs，这意味着它们可以将传入的数据包 DMA 到 RAM 中的许多环形缓冲区中的一个。我们就会看到，这样的 NICs 能够利用多个处理器来处理传入的网络数据。为简单起见，上图仅显示了一个环形缓冲区，但根据您使用的 NIC 和硬件设置，您的系统上可能有多个队列。

阅读有关下面描述的过程的更多详细信息 in this section of the networking blog post.

让我们来看看接收数据的过程：

1. 数据由 NIC 从网络接收。
2. NIC 使用 DMA 将网络数据写入 RAM。
3. NIC 发出 IRQ。
4. 执行设备驱动程序注册的 IRQ 处理程序。
5. IRQ 在 NIC 上被清除，以便它可以为新的数据包到达生成 IRQ。
6. NAPI softIRQ 轮询循环是以调用 napi_schedule 开始。

对 napi_schedule 的调用触发了上图中步骤 5 - 8 。正如我们将看到的，NAPI softIRQ 轮询循环操作启动是通过简单地置位位域中的位并将结构添加到 poll_list 来进行处理。napi_schedule 并没有再进行其他工作，这正是驱动程序将处理推迟到 softIRQ 系统的方式。

继续上一节中的图表标示的数字分析：

5. 驱动程序中对 napi_schedule 的调用使驱动程序的 NAPI 轮询结构添加到当前 CPU 的 poll_list 中。

6. 设置 softirq 挂起位，以便该 CPU 上的 ksoftirqd 进程知道有数据包要处理。

7. run_ksoftirqd 函数（由 ksoftirq 内核线程在循环中运行）执行。

8. __do_softirq 被调用，它检查挂起的位域，看到一个 softIRQ 正在挂起，并调用为挂起的 softIRQ 注册的处理程序：net_rx_action 为传入的网络数据处理完成所有繁重的工作。

需要注意的是，softIRQ 内核线程正在执行的是 net_rx_action，而不是设备驱动程序 IRQ 处理程序。

Network data processing begins

现在，数据处理开始。net_rx_action 函数（从 ksoftirqd 内核线程调用）将开始处理已添加到当前 CPU 的 poll_list 的 NAPI 轮询结构。轮询结构一般在两种情况下添加：

• 从设备驱动程序调用 napi_schedule
• With an Inter-processor Interrupt in the case of Receive Packet Steering. Read more about how Receive Packet Steering uses IPIs to process packets.

我们将首先从 poll_list 获取驱动程序的 NAPI 结构时会发生什么介绍。（下一节 NAPI 结构如何注册到 用于 RPS 处理的IPIs）。

上图在此处here进行了深入解释，但可以总结如下：

1. net_rx_action 循环首先检查 NAPI 轮询列表的 NAPI 结构。

2. 检查预算和运行时间以确保 softIRQ 不会独占 CPU 时间。

3. 调用注册的轮询函数。 在这种情况下，就是由 igb 驱动程序注册的 igb_poll 函数。

4. 驱动程序的轮询功能从 RAM 中的环形缓冲区收集数据包（harvests packets from the ring buffer in RAM）。

5. 数据包被移交给 napi_gro_receive，它将处理可能的Generic Receive Offloading。

6. 数据包要么为 GRO 保留并且调用链在此结束，要么数据包被传递到 net_receive_skb 以继续前进到协议栈。

接下来我们将看到 netif_receive_skb 如何控制以在多个 CPU 之间均衡分配数据包处理。

Network data processing continues

网络数据处理从 netif_receive_skb 继续，但数据的路径取决于是否启用了接收数据包控制 (RPS)。缺省的 Linux 内核默认不会启用 RPS，如果您想使用它，则需要明确启用和配置它。

在禁用 RPS 的情况下，使用上图中的数字如下：

• 1. netif_receive_skb 将数据传递给 __netif_receive_core。
• 6. __netif_receive_core 将数据传送到任何抓包程序（如 PCAP）。
• 7. __netif_receive_core 将数据传送到注册的协议层处理程序。在许多情况下，这将是 IPv4 协议栈已注册的 ip_rcv 函数。

在启用 RPS 的情况下：

• 1. netif_receive_skb 将数据传递给 enqueue_to_backlog。
• 2. 数据包放置在每个 CPU 的输入队列中进行处理。
• 3. 远程 CPU 的 NAPI 结构被添加到该 CPU 的 poll_list 中，一个 IPI 排队，如果它尚未运行，它将触发远程 CPU 上的 softIRQ 内核线程唤醒
• 4. 当远程 CPU 上的 ksoftirqd 内核线程运行时，它遵循上一节中描述的相同模式处理，但这一次，注册的轮询函数是 process_backlog，它将从当前 CPU 的输入队列中收集数据包。
• 5. 数据包被传递到 __net_receive_skb_core
• 6. __netif_receive_core 将数据传送到任何抓包程序（如 PCAP）
• 7. __netif_receive_core 将数据传送到注册的协议层处理程序。 在许多情况下，这将是 IPv4 协议栈已注册的 ip_rcv 函数

Protocol stacks and userland sockets

接下来是协议栈、netfilter、berkley 包过滤器，最后是用户态套接字。这段代码路径很长，但线性且相对简单。

您可以继续按照网络数据的详细路径进行学习。 该描述的一个非常简短的高级摘要是：

1. IPv4 协议层使用 ip_rcv 接收数据包。
2. 执行 Netfilter 和路由优化。
3. 发往当前系统的数据被传送到更高级别的协议层，如 UDP。
4. UDP 协议层使用 udp_rcv 接收数据包，并通过 udp_queue_rcv_skb 和 sock_queue_rcv 将数据包排队到用户态套接字的接收缓冲区。 在排队到接收缓冲区之前，berkeley数据包过滤器要先进行处理。

请注意，在整个过程中多次提到 netfilter。 确切的位置可以在我们的详细描述中找到。found in our detailed walk-through

Conclusion

Linux 网络堆栈极其复杂，并且有许多不同的系统相互作用。 任何调整或监控这些复杂系统的努力都必须了解所有这些系统之间的相互作用以及一个系统中更改设置将如何影响其他系统。

这篇（简单）插图的博客文章试图使我们较长的博客文章更易于管理和理解。

这篇关于Illustrated Guide to Monitoring and Tuning the Linux Networking Stack: Receiving Data的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---