Linux内核报文收发-网卡部分

https://zhaozhanxu.com/archives/page/7/ 

Linux版本： 3.10.103
网卡驱动： ixgbe

报文收发简单流程

---

网卡驱动默认采用的是NAPI的报文处理方式。即中断+轮询的方式，网卡收到一个报文之后会产生接收中断，并且屏蔽中断，直到收够了netdev_max_backlog个报文(默认300)或者收完网卡上的所有报文之后，重新打开中断。

网卡数据处理

---

网卡初始化

• 内核启动时会调用do_initcalls，从而调用注册的初始化接口net_dev_init，net_dev_init注册软中断的回调函数,分别为接收和发送的：NET_RX_SOFTIRQ = net_rx_action，NET_TX_SOFTIRQ = net_tx_action。
• 网卡驱动加载时调用ixgbe_init_module注册一个PCI驱动。
• 接着调用probe对应的ixgbe_probe做一些准备工作如下：
  • 创建ixgbe_adapter数据结构，这是网卡的一个实例，其中包含了网卡的所有数据和接口(netdev)。
  • netdev注册了网卡的所有操作：ixgbe_netdev_ops和网卡的features。
  • ixgbe_init_interrupt_scheme主要是设置网卡的NAPI对应的poll接口，这里主要是ixgbe_poll。
• 网卡激活时会调用netdev上的open函数ixgbe_open，完成工作如下：
  • 设置接收和发送队列，通过DMA讲PCI网卡地址和队列建立映射。
  • 给网卡注册硬中断：ixgbe_open-->ixgbe_request_irq-->ixgbe_request_msix_irqs注册中断回调ixgbe_msix_clean_rings。(MSIX中断时)
• ixgbe_close函数所做的事情：
  • 关闭中断并且释放中断向量号。
  • 释放申请的相应空间。

网卡收发数据

• 当网卡接收到数据帧时，DMA将数据搬运到对应的rx_ring，然后产生一个硬中断，调用接口ixgbe_msix_clean_rings。
• 硬中断回调函数ixgbe_msix_clean_rings会调用当前CPU对应的NET_RX_SOFTIRQ，即net_rx_action。其中的主要实现NAPI操作如下：
  • 关闭硬中断。
  • 调用该CPU的poll_list中的所有poll函数，即ixgbe_poll。
  • 开启硬中断。
• 轮询函数ixgbe_poll主要是处理接收发送任务：
  • 循环处理每个ring中的数据，ixgbe_clean_tx_irq，此处发送tx_work_limit个报文(128)或者没有报文后完成，并且调用netif_wake_subqueue触发发送软中断NET_TX_SOFTIRQ，即net_tx_action。
  • 循环处理每个ring中的数据，ixgbe_clean_rx_irq，此处接收weight个报文(64)，总共收取netdev_budget(300)个，并且调用ixgbe_rx_skb进行下一步的处理。
• ixgbe_rx_skb最终会处理过GRO之后调用到netif_receive_skb，此处忽略rps。
• netif_receive_skb最终调用__netif_receivve_skb_core进入协议栈处理各种协议。
  • 首先根据下面介绍的rx_handler类型调用ovs或者桥处理函数进入L2的处理。
  • 然后根据pttype_base处理相关的L3协议处理。

备注

• ixgbe拥有64个rx_ring，每个ring默认有512个buffer，最小64，最大4096。
• 由以上可知网卡默认可以缓存32768个报文，当网卡接收报文的速度过快，接收软中断无法处理的时候，系统进入扼流(throttle)状态，所有后续的报文都被丢弃，直到rx_ring有空间了。
• 通过DMA地址映射的方式，网卡接收数据相当于零拷贝。

TUN虚拟网卡

---

• 网卡驱动加载时调用tun_init注册一个MISC驱动，生成/dev/net/tun的设备文件。
• 接着调用open对应的tun_chr_open做主要创建socket。
• 随后调用ioctl对应的tun_chr_ioctl，完成一些需要的配置和信息获取，包括校验、连接状态、offload、mac等。
• 通过调用write发送报文，主要是调用tun_chr_aio_write生成skb格式报文，最终通过调用netif_rx进入协议栈，通过三层转发到对应的端口发送。
• 通过调用read接收报文，主要是调用tun_chr_aio_read，从内核对应的sock队列上拿到报文，然后将数据上传到用户层。

注:
因为网卡接收报文后最终经过四层的时候，会将报文根据协议几元组找到对应的sock结构，放入队列。上层调用read或者recv的时候都是从socket对应的sock结构队列上取数据。

 

tun虚拟网卡流程图

VETH虚拟网卡

---

• 网卡驱动加载时调用veth_init注册一个netlink驱动。
• 接着调用newlink对应的veth_newlink，创建两个网络设备，两者互为对方的peer。
• 发送报文时会调用ndo_start_xmit对应的veth_xmit，实际操作为将skb的dev设置为自己的peer，调用到netif_rx接收到协议栈。

 

veth虚拟网卡示意图

QEMU虚拟机网络通信

---

• 主机vhost驱动加载时调用vhost_net_init注册一个MISC驱动，生成/dev/vhost-net的设备文件。
• 主机qemu-kvm启动时调用open对应的vhost_net_open做主要创建队列和收发函数的挂载，接着调用ioctl启动内核线程vhost，做收发包的处理。
• 主机qemu通过ioctl配置kvm模块，主要设置通信方式，因为主机vhost和virtio只进行报文的传输，kvm进行提醒。
• 虚拟机virtio模块注册，生成虚拟机的网络设备，配置中断和NAPI。
• 虚拟机发包流程如下：
  • 直接从应用层走协议栈最后调用发送接口ndo_start_xmit对应的start_xmit，将报文放入发送队列，vp_notify通知kvm。
  • kvm通过vmx_handle_exit一系列调用到wake_up_process唤醒vhost线程。
  • vhost模块的线程激活并且拿到报文，在通过之前绑定的发送接口handle_tx_kick进行发送，调用虚拟网卡的tun_sendmsg最终到netif_rx接口进入主机内核协议栈。
• 虚拟机收包流程如下：
  • tap设备的ndo_start_xmit对应的tun_net_xmit最终调用到wake_up_process激活vhost线程，调用handle_rx_kick，将报文放入接收队列。
  • 通过一系列的调用到kvm模块的接口kvm_vcpu_kick，向qemu虚拟机注入中断。
  • 虚拟机virtio模块中断调用接口vp_interrupt，调用virtnet_poll，再调用到netif_receive_skb进入虚拟机的协议栈。

 

qemu虚拟机通信流程图

Offload技术

---

发送数据

• TSO(TCP Segmentation Offload)使得网络协议栈能够将大块buffer推送至网卡，然后网卡执行分片工作，这样减轻了CPU 的负荷，但TSO需要硬件来实现分片功能，也叫LSO。
• UFO(UDP Fragmentation Offload)类似。
• GSO(Generic Segmentation Offload)，它比TSO更通用，基本思想就是尽可能的推迟数据分片直至发送到网卡驱动之前，此时会检查网卡是否支持分片功能(如TSO、UFO)，如果支持直接发送到网卡，如果不支持就进行回调分片后再发往网卡。这样大数据包只需走一次协议栈，而不是被分割成几个数据包分别走，这就提高了效率。

接收数据

• LRO(Large Receive Offload)通过将接收到的多个TCP数据聚合成一个大的数据包，然后传递给网络协议栈处理，以减少上层协议栈处理开销，提高系统接收TCP数据包的能力。
• GRO(Generic Receive Offloading)，LRO使用发送方和目的地IP地址，IP封包ID，L4协议三者来区分段，对于从同一个SNAT域的两个机器发向同一目的IP的两个封包可能会存在相同的IP封包ID(因为不是全局分配的ID)，这样会有所谓的卷绕的bug。GRO采用发送方和目的地IP地址，源/目的端口，L4协议三者来区分作为改进。所以对于后续的驱动都应该使用GRO的接口，而不是LRO。另外，GRO也支持多协议。

OpenvSwitch ovs-dpdk安装

Linux内核报文收发-2层报文处理

注意:所有文章非特别说明皆为原创。为保证信息与源同步，转载时请务必注明文章出处！谢谢合作 :-)

原始链接:http://zhaozhanxu.com/2016/07/12/Linux/2016-07-12-Linux-Kernel-Pkts_Processing1/

许可协议: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。

 

另一些文章：

https://blog.csdn.net/meituantech/article/details/80062289  Redis 高负载下的中断优化

软中断部分有几个地方会有类似if (static_key_false(&rps_needed))这样的判断，会进入前文所述有丢包风险的enqueue_to_backlog函数。 这里的逻辑为判断是否启用了RPS机制，RPS是早期单队列网卡上将软中断负载均衡到多个CPU Core的技术，它对数据流进行hash并分配到对应的CPU Core上，发挥多核的性能。不过现在基本都是多队列网卡，不会开启这个机制，因此走不到这里，static_key_false是针对默认为false的static key 的优化判断方式。这段调用的最后，deliver_skb会将接收的数据传入一个IP层的数据结构中，至此完成二层的全部处理.

关于ixgbe的rx ring，tx ring，msi，legacy对比 https://www.slideshare.net/suselab/ixgbe-internals:

ixgbe 网卡初始化及收发数据概览 https://www.jianshu.com/p/9a78390df5b9