1. 接收数据包过程概述
介绍数据包收包过程，有助于我们了解Linux内核网络设备在数据收包过程中的位置，下面从宏观的角度介绍数据包从被网卡接收到进入 socket 接收队列的整个过程：
加载网卡驱动，初始化
数据包从外部网络进入网卡
网卡（通过DMA）将包拷贝到内核内存中的ring buffer
产生硬件中断，通知系统收到了一个包
驱动调用 NAPI ，如果轮询（poll）还没有开始，就开始轮询
ksoftirqd软中断调用 NAPI 的poll函数从ring buffer收包（poll 函数是网卡驱动在初始化阶段注册的；每个cpu上都运行着一个ksoftirqd进程，在系统启动期间就注册了）
ring buffer里面对应的内存区域解除映射（unmapped）
如果 packet steering 功能打开，或者网卡有多队列，网卡收到的数据包会被分发到多个cpu
数据包从队列进入协议层
协议层处理数据包
数据包从协议层进入相应 socket 的接收队列
下面以常见的Intel I350 网卡的驱动 ibg 为例介绍它的工作过程：
驱动会使用module_init向内核注册一个初始化函数，当驱动被加载时，内核会调用这个函数。在drivers/net/ethernet/intel/igb/igb_main.c中初始化函数（igb_init_module）：
/*** igb_init_module - Driver Registration Routine** igb_init_module is the first routine called when the driver is* loaded. All it does is register with the PCI subsystem.**/static int __init igb_init_module(void){int ret;pr_info("%s - version %s\n", igb_driver_string, igb_driver_version);pr_info("%s\n", igb_copyright);/* ... */ret = pci_register_driver(&igb_driver);return ret;}module_init(igb_init_module);
初始化的大部分工作在pci_register_driver中完成。
Intel I350 网卡是 PCI express 设备。PCI 设备通过PCI Configuration Space 里面的寄存器识别自己。
PCI express 总线是一种完全不同于过去PCI总线的一种全新总线规范，与PCI总线共享并行架构相比，PCI Express总线是一种点对点串行连接的设备连接方式，点对点意味着每一个PCI Express设备都拥有自己独立的数据连接，各个设备之间并发的数据传输互不影响，而对于过去PCI那种共享总线方式，PCI总线上只能有一个设备进行通信，一旦PCI总线上挂接的设备增多，每个设备的实际传输速率就会下降，性能得不到保证。PCI Express以点对点的方式处理通信，每个设备在要求传输数据的时候各自建立自己的传输通道，对于其他设备这个通道是封闭的，这样的操作保证了通道的专有性，避免其他设备的干扰。
当设备驱动编译时，MODULE_DEVICE_TABLE 宏（定义在 include/module.h） 会导出一个 PCI 设备 ID 列表（a table of PCI device IDs），驱动据此识别它可以控制的设备，内核也会依据这个列表对不同设备加载相应驱动。
igb 驱动的设备表和 PCI 设备 ID 分别见：drivers/net/ethernet/intel/igb/igb_main.c 和drivers/net/ethernet/intel/igb/e1000_hw.h。
static DEFINE_PCI_DEVICE_TABLE(igb_pci_tbl) = {{ PCI_VDEVICE(INTEL, E1000_DEV_ID_I354_BACKPLANE_1GBPS) },{ PCI_VDEVICE(INTEL, E1000_DEV_ID_I354_SGMII) },{ PCI_VDEVICE(INTEL, E1000_DEV_ID_I354_BACKPLANE_2_5GBPS) },{ PCI_VDEVICE(INTEL, E1000_DEV_ID_I211_COPPER), board_82575 },{ PCI_VDEVICE(INTEL, E1000_DEV_ID_I210_COPPER), board_82575 },{ PCI_VDEVICE(INTEL, E1000_DEV_ID_I210_FIBER), board_82575 },{ PCI_VDEVICE(INTEL, E1000_DEV_ID_I210_SERDES), board_82575 },{ PCI_VDEVICE(INTEL, E1000_DEV_ID_I210_SGMII), board_82575 },{ PCI_VDEVICE(INTEL, E1000_DEV_ID_I210_COPPER_FLASHLESS), board_82575 },{ PCI_VDEVICE(INTEL, E1000_DEV_ID_I210_SERDES_FLASHLESS), board_82575 },/* ... */};MODULE_DEVICE_TABLE(pci, igb_pci_tbl);
前面提到，驱动初始化的时候会调用 pci_register_driver，这个函数会将该驱动的各种回调方法注册到一个 struct pci_driver 变量，drivers/net/ethernet/intel/igb/igb_main.c：
static struct pci_driver igb_driver = {.name = igb_driver_name,.id_table = igb_pci_tbl,.probe = igb_probe,.remove = igb_remove,/* ... */};
通过 PCI ID 识别设备后，内核就会为它选择合适的驱动。每个 PCI 驱动注册了一个 probe() 方法，内核会对每个设备依次调用其驱动的 probe 方法，一旦找到一个合适的驱动，就不会再为这个设备尝试其他驱动。
很多驱动都需要大量代码来使得设备 ready，具体做的事情各有差异。典型的过程：
启用 PCI 设备
请求（requesting）内存范围和 IO 端口
设置 DMA 掩码
注册设备驱动支持的 ethtool 方法（后面介绍）
注册所需的 watchdog（例如，e1000e 有一个检测设备是否僵死的 watchdog）
其他和具体设备相关的事情，例如一些 workaround，或者特定硬件的非常规处理
创建、初始化和注册一个 struct net_device_ops 类型变量，这个变量包含了用于设备相关的回调函数，例如打开设备、发送数据到网络、设置 MAC 地址等
创建、初始化和注册一个更高层的 struct net_device 类型变量（一个变量就代表了 一个设备）
下面来看 igb 驱动的 igb_probe 包含哪些过程（drivers/net/ethernet/intel/igb/igb_main.c）：
err = pci_enable_device_mem(pdev);/* ... */err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));/* ... */err = pci_request_selected_regions(pdev, pci_select_bars(pdev,IORESOURCE_MEM),igb_driver_name);pci_enable_pcie_error_reporting(pdev);pci_set_master(pdev);pci_save_state(pdev);
更详细的过程可以查看内核文档：https://github.com/torvalds/linux/blob/v3.13/Documentation/PCI/pci.txt
igb_probe 做了很多重要的设备初始化工作。除了 PCI 相关的，还有如下一些通用网络功能和网络设备相关的工作：
注册 struct net_device_ops 变量
注册 ethtool 相关的方法
从网卡获取默认 MAC 地址
设置 net_device 特性标记
网络设备相关的操作函数都注册到struct net_device_ops类型的变量中（drivers/net/ethernet/intel/igb/igb_main.c）:
static const struct net_device_ops igb_netdev_ops = {.ndo_open = igb_open,.ndo_stop = igb_close,.ndo_start_xmit = igb_xmit_frame,.ndo_get_stats64 = igb_get_stats64,.ndo_set_rx_mode = igb_set_rx_mode,.ndo_set_mac_address = igb_set_mac,.ndo_change_mtu = igb_change_mtu,.ndo_do_ioctl = igb_ioctl,/* ... */
这个变量会在igb_probe()中赋给struct net_device中的netdev_ops字段：
static int igb_probe(struct pci_dev *pdev, const struct pci_device_id *ent){...netdev->netdev_ops = &igb_netdev_ops;}
ethtool 是一个命令行工具，可以查看和修改网络设备的一些配置，常用于收集网卡统计数据。在 Ubuntu 上，可以 通过 apt-get install ethtool 安装，过会演示通过此工具监控网卡数据。
ethtool 通过 ioctl 和设备驱动通信。内核实现了一个通用 ethtool 接口，网卡驱动实现这些接口，就可以被 ethtool 调用。当 ethtool 发起一个系统调用之后，内核会找到对应操作的回调函数 。回调实现了各种简单或复杂的函数，简单的如改变一个 flag 值，复杂的包括调整网卡硬件如何运行。
相关实现见:drivers/net/ethernet/intel/igb/igb_ethtool.c。
当一个数据帧通过 DMA 写到 RAM（内存）后，网卡是如何通知其他系统这个包可以被处理了呢？
传统的方式是，网卡会产生一个硬件中断（IRQ），通知数据包到了。有三种常见的硬中断类型：
MSI-X
MSI
legacy IRQ
如果有大量的数据包到达，就会产生大量的硬件中断。CPU 忙于处理硬件中断的时候，可用于处理其他任务的时间就会减少。
NAPI（New API）是一种新的机制，可以减少产生的硬件中断的数量（但不能完全消除硬中断 ）。
NAPI 接收数据包的方式和传统方式不同，它允许设备驱动注册一个 poll 方法，然后调用这个方法完成收包。
NAPI 的使用方式：
驱动打开 NAPI 功能，默认处于未工作状态（没有在收包）
数据包到达，网卡通过 DMA 写到内存
网卡触发一个硬中断，中断处理函数开始执行
软中断（softirq），唤醒 NAPI 子系统。这会触发在一个单独的线程里， 调用驱动注册的 poll 方法收包
驱动禁止网卡产生新的硬件中断，这样做是为了 NAPI 能够在收包的时候不会被新的中断打扰
一旦没有包需要收了，NAPI 关闭，网卡的硬中断重新开启
转步骤 2
和传统方式相比，NAPI 一次中断会接收多个包，因此可以减少硬件中断的数量。
poll 方法是通过调用 netif_napi_add 注册到 NAPI 的，同时还可以指定权重 weight，大部分驱动都 hardcode 为 64。
通常来说，驱动在初始化的时候注册 NAPI poll 方法。
igb 驱动的初始化过程是一个很长的调用链：
igb_probe -> igb_sw_init
igb_sw_init -> igb_init_interrupt_scheme
igb_init_interrupt_scheme -> igb_alloc_q_vectors
igb_alloc_q_vectors -> igb_alloc_q_vector
igb_alloc_q_vector -> netif_napi_add
从宏观角度来看，这个调用过程会做以下事情：
如果支持 MSI-X，调用 pci_enable_msix 打开它
计算和初始化一些配置，包括网卡收发队列的数量
调用 igb_alloc_q_vector 创建每个发送和接收队列
igb_alloc_q_vector 会进一步调用 netif_napi_add 注册 poll 方法到 NAPI 变量
下面介绍 igb_alloc_q_vector 是如何注册 poll 方法和私有数据的（drivers/net/ethernet/intel/igb/igb_main.c）：
static int igb_alloc_q_vector(struct igb_adapter *adapter,int v_count, int v_idx,int txr_count, int txr_idx,int rxr_count, int rxr_idx){/* ... *//* allocate q_vector and rings */q_vector = kzalloc(size, GFP_KERNEL);if (!q_vector)return -ENOMEM;/* initialize NAPI */netif_napi_add(adapter->netdev, &q_vector->napi, igb_poll, 64);/* ... */
q_vector 是新分配的队列，igb_poll 是 poll 方法，当它收包的时候，会通过这个接收队列找到关联的 NAPI 变量（q_vector->napi）。
前面提到structure net_device_ops 变量，它包含网卡启用、发包、设置 mac 地址等回调函数（函数指针）。
当启用一个网卡时（例如，通过 ifconfig eth0 up），net_device_ops 的 ndo_open 方法会被调用。它通常会做以下事情：
分配 RX、TX 队列内存
打开 NAPI 功能
注册中断处理函数
打开（enable）硬中断
其他
igb 驱动中，这个方法对应的是 igb_open 函数。
目前大部分网卡都使用 DMA 将数据直接写到内存，接下来操作系统可以直接从里面读取。实现这一目的所使用的数据结构是 ring buffer（环形缓冲区）。
要实现这一功能，设备驱动必须和操作系统合作，预留（reserve）出一段内存来给网卡使用。预留成功后，网卡知道了这块内存的地址，接下来收到的数据包就会放到这里，进而被操作系统取走。
由于这块内存区域是有限的，如果数据包的速率非常快，单个 CPU 来不及取走这些包，新来的包就会被丢弃。这时候，Receive Side Scaling（RSS，接收端扩展）或者多队列（ multiqueue）一类的技术可能就会排上用场。
一些网卡有能力将接收到的数据包写到多个不同的内存区域，每个区域都是独立的接收队列。这样操作系统就可以利用多个 CPU（硬件层面）并行处理收到的数据包。只有部分网卡支持这个功能。
Intel I350 网卡支持多队列，我们可以在 igb 的驱动里看出来。igb 驱动启用的时候 ，最开始做的事情之一就是调用 igb_setup_all_rx_resources 函数。这个函数会对每个 RX 队列调用 igb_setup_rx_resources， 里面会管理 DMA 的内存。
RX 队列的数量和大小可以通过 ethtool 进行配置，调整这两个参数会对收包或者丢包产生可见影响。
网卡通过对 packet 头（例如源地址、目的地址、端口等）做哈希来决定将 packet 放到哪个 RX 队列。只有很少的网卡支持调整哈希算法。如果支持的话，可以根据算法将特定 的 flow 发到特定的队列，甚至可以做到在硬件层面直接将某些包丢弃。
一些网卡支持调整 RX 队列的权重，可以有意地将更多的流量发到指定的 queue。
前面介绍了驱动如何注册 NAPI poll 方法，但是，一般直到网卡被启用之后，NAPI 才被启用。
启用 NAPI 很简单，调用 napi_enable 函数就行，这个函数会设置 NAPI 变量（struct napi_struct）中一个表示是否启用的标志位。前面说到，NAPI 启用后并不是立即开始工作（而是等硬中断触发）。
对于 igb，驱动初始化或者通过 ethtool 修改 queue 数量或大小的时候，会启用每个 q_vector 的 NAPI 变量（ drivers/net/ethernet/intel/igb/igb_main.c）：
for (i = 0; i < adapter->num_q_vectors; i++)napi_enable(&(adapter->q_vector[i]->napi));
启用 NAPI 之后，下一步就是注册中断处理函数。设备有多种方式触发一个中断：
MSI-X
MSI
legacy interrupts
设备驱动的实现也因此而异。驱动必须判断出设备支持哪种中断方式，然后注册相应的中断处理函数，这些函数在中断发生的时候会被执行。
一些驱动，例如 igb，会试图为每种中断类型注册一个中断处理函数，如果注册失败，就尝试下一种类型。
MSI-X 中断是比较推荐的方式，尤其是对于支持多队列的网卡。因为每个 RX 队列有独立的 MSI-X 中断，因此可以被不同的 CPU 处理（通过 irqbalance 方式，或者修改 /proc/irq/IRQ_NUMBER/smp_affinity）。处理中断的 CPU 也是随后处理这个包的 CPU。这样的话，从网卡硬件中断的层面就可以设置让收到的包被不同的 CPU 处理。
如果不支持 MSI-X，那 MSI 相比于传统中断方式仍然有一些优势，驱动仍然会优先考虑它。
在 igb 驱动中，函数 igb_msix_ring，igb_intr_msi，igb_intr 分别是 MSI-X，MSI 和传统中断方式的中断处理函数。
驱动是如何尝试各种中断类型的（ drivers/net/ethernet/intel/igb/igb_main.c）：
static int igb_request_irq(struct igb_adapter *adapter){struct net_device *netdev = adapter->netdev;struct pci_dev *pdev = adapter->pdev;int err = 0;if (adapter->msix_entries) {err = igb_request_msix(adapter);if (!err)goto request_done;/* fall back to MSI *//* ... */}/* ... */if (adapter->flags & IGB_FLAG_HAS_MSI) {err = request_irq(pdev->irq, igb_intr_msi, 0,netdev->name, adapter);if (!err)goto request_done;/* fall back to legacy interrupts *//* ... */}err = request_irq(pdev->irq, igb_intr, IRQF_SHARED,netdev->name, adapter);if (err)dev_err(&pdev->dev, "Error %d getting interrupt\n", err);request_done:return err;}
这就是 igb 驱动注册中断处理函数的过程，这个函数在一个数据包到达网卡触发一个硬件中断时就会被执行。
到这里，几乎所有的准备工作都就绪了。唯一剩下的就是打开硬中断，等待数据包进来。打开硬中断的方式因硬件而异，igb 驱动是在 __igb_open 里调用辅助函数 igb_irq_enable 完成的。
中断通过写寄存器的方式打开：
static void igb_irq_enable(struct igb_adapter *adapter){/* ... */wr32(E1000_IMS, IMS_ENABLE_MASK | E1000_IMS_DRSTA);wr32(E1000_IAM, IMS_ENABLE_MASK | E1000_IMS_DRSTA);/* ... */}
现在，网卡已经启用了。驱动可能还会做一些额外的事情，例如启动定时器，工作队列（ work queue），或者其他硬件相关的设置。这些工作做完后，网卡就可以接收数据包了。
监控网络设备有几种不同的方式，每种方式的监控粒度（granularity）和复杂度不同。我们先从最粗的粒度开始，逐步细化。
ethtool -Sethtool -S 可以查看网卡统计信息（例如接收和发送的数据包总数，接收和发送的流量，丢弃的包数量，错误的数据包数量等）：
监控这些数据比较困难。因为用命令行获取很容易，但是以上字段并没有一个统一的标准。不同的驱动，甚至同一驱动的不同版本可能字段都会有差异。
可以先粗略的查看 “drop”, “buffer”, “miss” 等字样。然后，在驱动的源码里找到对应的更新这些字段的地方，这可能是在软件层面更新的，也有可能是在硬件层面通过寄存器更新的。如果是通过硬件寄存器的方式，就得查看网卡的 data sheet（说明书），搞清楚这个寄存器代表什么。ethtoool 给出的这些字段名，有一些是有误导性的（misleading）。
sysfssysfs 也提供了统计信息，但相比于网卡层的统计，要更上层一些。
例如，可以获取的 ens33 的接收端数据包的类型有这些：
获取接收到的数据包的总数为：
不同类型的统计分别位于 /sys/class/net/ 下面的不同文件，包括 collisions, rx_dropped, rx_errors, rx_missed_errors 等等。
要注意的是，每种类型代表什么意思，是由驱动来决定的，因此也是由驱动决定何时以及在哪里更新这些计数的。你可能会发现一些驱动将一些特定类型的错误归类为 drop，而另外一些驱动可能将它们归类为 miss。
这些值至关重要，因此需要查看对应的网卡驱动，搞清楚它们真正代表什么。
/proc/net/dev/proc/net/dev 提供了更高一层的网卡统计。
这个文件里显示的统计只是 sysfs 里面的一个子集，但适合作为一个常规的统计参考。
如果对这些数据准确度要求特别高，那必须查看内核源码 、驱动源码和驱动手册，搞清楚每个字段真正代表什么意思，计数是如何以及何时被更新的。Linux内核网络设备驱动先介绍到这里，感谢阅读。
参考链接：
https://blog.packagecloud.io/eng/2016/06/22/monitoring-tuning-linux-networking-stack-receiving-data/
end
一口Linux
关注，回复【1024】海量Linux资料赠送
精彩文章合集
文章推荐
点击“阅读原文”查看更多分享，欢迎点分享、收藏、点赞、在看
