嵌入式开发笔记

从一根网线到一个 skb：RK3588 STMMAC 与 RTL8211F 网卡驱动全景解析

2026-07-16T08:30:00.000Z

很多网卡问题都有一种迷惑性：

MDIO 能读到 PHY ID，但接口始终 NO-CARRIER；
ethtool 显示 1000 Mbps、Link detected: yes，却 ping 不通；
百兆稳定，千兆一跑 iperf3 就出现 CRC error；
开机前几秒能收包，随后 RX 停止；
低流量正常，并发或大包时 TX timeout；
关闭 checksum/TSO/GRO 后“神奇恢复”。

这些现象之所以难排，是因为我们口中的“网卡驱动”其实横跨多个软硬件层：RK3588 内部的 Synopsys DWMAC、Rockchip 的 GRF/clock/reset glue、外置 RTL8211F PHY、RGMII 数据总线、MDIO 管理总线、Linux stmmac、phylink/phylib、NAPI、DMA 和网络协议栈。

如果只盯着 stmmac_main.c 的某一个函数，或者只盯着 PHY 的 link 状态，就很容易在错误的层次上修问题。

本文以本地 Firefly RK3588 SDK 的 Linux 5.10.198 为样本，建立一套可迁移到其他 SoC 网卡的完整理解框架：

MAC、PHY、RGMII、MDIO 各自负责什么；
一个 Linux 网卡驱动到底要实现哪些能力；
dwmac-rk、stmmac、phylink、phylib 和 realtek.c 如何分工；
probe、open、link、TX、RX、IRQ/NAPI 的完整调用链；
descriptor、DMA buffer 与 skb 的所有权如何转移；
为什么 RGMII delay 是 RK3588 千兆网口最关键的板级边界；
面对“找不到 PHY”“link up 不通”“千兆不稳”时如何分层定位。

本文讨论的是 RK3588 + 外置 RTL8211F 千兆 PHY 的典型 RGMII 场景。不同 Firefly 板型可能连接 GMAC0 或 GMAC1，也可能使用其他 PHY；最终应以原理图和实际启动 DTB 为准。

一、先拆掉第一个误区：网卡不是一个硬件块

1. MAC：处理以太网帧与 DMA

RK3588 集成 Synopsys DesignWare Ethernet MAC。MAC 处于数字世界，主要负责：

接收和发送以太网帧；
生成、检查 FCS；
MAC 地址过滤、组播过滤；
VLAN、checksum、TSO、RSS、时间戳等硬件卸载；
管理 MAC/MTL FIFO 和多队列；
通过 DMA descriptor 在 FIFO 与 DDR packet buffer 之间搬运数据；
产生 RX、TX completion、DMA error、LPI 等中断。

Linux stmmac 的主要工作对象就是这个 MAC、MTL 和 DMA。

2. PHY：处理双绞线上的物理信号

RTL8211F 是独立的千兆以太网 PHY。它负责：

10BASE-T、100BASE-TX、1000BASE-T 的模拟前端和物理编码；
自动协商、千兆主从训练；
速度、双工和 pause 能力协商；
均衡、回波抵消等 PHY 内部信号处理；
报告 link、speed、duplex、pause；
PHY 私有低功耗、中断和 delay 配置。

PHY 不知道 struct sk_buff，也不管理 DMA ring。它面对的是 RGMII 数字接口和 MDI 双绞线接口。

3. RGMII：MAC 与 PHY 的数据通道

RGMII 承载实际帧数据。GMAC 与 RTL8211F 之间通过 TXD/RXD、TXC/RXC 和控制线交换数据。

千兆模式下时钟为 125 MHz，并在时钟双沿传输。正因为采样窗口很窄，RGMII 对 clock-data skew 极其敏感，这也是“百兆正常、千兆异常”的高发根因。

4. MDIO/MDC：MAC 管理 PHY 的控制通道

MDIO 是另一条独立总线：

MAC 内的 MDIO controller 是 bus master；
PHY 是具有地址的从设备；
Linux 通过 MDIO 读取 PHY ID、基本状态和厂商扩展寄存器。

因此必须牢记两条判断：

MDIO 能读到 PHY ID，只能证明管理通路基本正常，不能证明 RGMII 数据通路正确。

PHY 显示 link up，只能证明 PHY 与链路对端完成了协商，不能证明 MAC DMA 与 Linux 收发路径正确。

二、Linux 为什么把它拆成五层驱动

RK3588 网口不是靠一个驱动文件完成，而是多层组合：

软件层	本地源码	解决的问题
设备树	`arch/arm64/boot/dts/rockchip/`	板子到底怎么连
Rockchip glue	`drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c`	通用 DWMAC 如何接入 RK3588
stmmac core	`drivers/net/ethernet/stmicro/stmmac/`	MAC/DMA 如何作为 Linux netdev 工作
phylink/phylib	`drivers/net/phy/`	MAC 与 PHY 如何协商能力和链路状态
Realtek PHY	`drivers/net/phy/realtek.c`	RTL8211F 有哪些私有初始化和寄存器

1. Rockchip glue 不负责逐包收发

dwmac-rk.c 的价值在于处理 SoC 差异：

GRF/PHP_GRF 接口 mux；
GMAC0/GMAC1 选择；
RGMII/RMII 模式；
参考时钟输入/输出；
10/100/1000 Mbps 分频；
SoC 侧 TX/RX delay line；
clock、reset、power domain；
suspend/resume 包装。

它完成板级准备后调用通用的 stmmac_dvr_probe()。

2. stmmac 是 MAC 数据路径主体

stmmac 负责：

创建和注册 net_device；
ndo_open、ndo_stop、ndo_start_xmit；
DMA descriptor ring；
RX buffer 与 TX DMA mapping；
IRQ 和 NAPI；
多 TX/RX queue；
checksum、TSO、VLAN、RSS、PTP、EEE；
ethtool、统计、TX timeout、PM；
注册 MDIO bus；
通过 phylink 接收链路变化。

3. phylink 是 MAC 与 PHY 的合同

PHY 能发现链路协商到了 1000 Mbps 全双工，但它不知道 RK3588 应该把哪个 GRF 分频位改成 DIV1；MAC 知道怎样配置自己，却不应该依赖某一个 Realtek 型号。

phylink 负责把双方隔离并协调：

MAC 支持哪些 interface 和速率；
PHY/PCS 当前解析出了什么状态；
link up/down 时调用哪个 MAC 回调；
speed、duplex、pause 变化如何传递。

4. phylib 提供 PHY 通用状态机

phylib 负责：

创建 phy_device；
读取 PHY ID 并匹配 phy_driver；
通用自动协商；
定时状态机或 PHY IRQ；
link/speed/duplex 状态更新；
suspend/resume 和通用 Clause 22/45 操作。

5. Realtek driver 只实现芯片差异

RTL8211F 的驱动无需重新实现整个自动协商协议。它主要补充：

芯片私有初始化；
RGMII internal delay；
PHY 中断 enable/ack；
paged register 访问；
低功耗或硬件 quirk。

这种分层不是“复杂化”，而是让一个 stmmac core 可以服务许多 SoC，让同一个 Realtek PHY driver 可以连接许多 MAC。

三、从设备树读懂一块板的网口

1. SoC 节点声明 DWMAC 实例

RK3588 的 GMAC0 定义在：

1	firefly_rk3588_SDK/kernel/arch/arm64/boot/dts/rockchip/rk3588.dtsi:690

GMAC1 定义在：

1	firefly_rk3588_SDK/kernel/arch/arm64/boot/dts/rockchip/rk3588s.dtsi:5500

两个节点都包含：

1	compatible = "rockchip,rk3588-gmac", "snps,dwmac-4.20a";

这两个 compatible 分别选择：

RK3588 平台 glue；
Synopsys DWMAC 4.20a 通用能力模型。

SoC 节点还描述 MMIO、MAC IRQ、wake IRQ、GRF、clock、reset、power domain、TSO 和 MDIO 子节点。

2. 板级 DTS 决定 PHY 和 RGMII 怎么接

Firefly SDK 的 rk3588-firefly-port.dtsi:179 提供了一个典型配置：

&gmac1 {
    phy-mode = "rgmii-rxid";
    clock_in_out = "output";

    snps,reset-gpio = <&gpio3 RK_PB7 GPIO_ACTIVE_LOW>;
    snps,reset-active-low;
    snps,reset-delays-us = <0 20000 100000>;

    pinctrl-0 = <&gmac1_miim
                 &gmac1_tx_bus2
                 &gmac1_rx_bus2
                 &gmac1_rgmii_clk
                 &gmac1_rgmii_bus>;

    tx_delay = <0x42>;
    phy-handle = <&rgmii_phy1>;
};

&mdio1 {
    rgmii_phy1: phy@1 {
        compatible = "ethernet-phy-ieee802.3-c22";
        reg = <0x1>;
    };
};

这段 DTS 同时回答了八个问题：

使用 GMAC1；
数据接口是 RGMII；
PHY 负责插入 RX internal delay；
参考时钟由 SoC 输出；
PHY reset 使用哪个 GPIO；
reset 前后延迟多长；
RK3588 SoC 侧 TX delay tap 是多少；
PHY 的 MDIO 地址是 1。

3. 不要只看某个 dtsi

这个示例文件中还出现了：

1	status = "disbaled";

对设备树来说，通常只有 okay/ok 表示可用，其他值都等价于不可用。真实板级文件可能在后面覆盖它，也可能没有。

所以判断运行配置时，证据优先级应当是：

1	实际启动 DTB > 最终板级 DTS 展开结果 > 某个被 include 的 dtsi

可以反编译实际 DTB：

1 2	dtc -I dtb -O dts -o /tmp/running.dts /sys/firmware/fdt rg -n 'ethernet@fe1b0000\|ethernet@fe1c0000\|phy-mode\|tx_delay\|rx_delay\|phy@1' /tmp/running.dts

四、最危险的板级参数：RGMII delay

1. 为什么 RGMII 需要 delay

RGMII 为减少引脚数量，在时钟上升沿和下降沿都发送数据。接收端需要在数据稳定窗口中间采样，因此时钟与数据之间需要大约 1.5～2 ns 的偏移。

这个偏移可以来自：

PCB 走线；
PHY 内部 delay；
SoC/GMAC 内部 delay line。

问题在于三者都可能“帮忙”。如果同一方向重复加入 delay，或者没有任何一方加入，就会把采样点推到窗口边缘之外。

2. `phy-mode` 是从 PHY 视角定义的

模式	PHY TX delay	PHY RX delay
`rgmii`	无	无
`rgmii-rxid`	无	有
`rgmii-txid`	有	无
`rgmii-id`	有	有

这里最容易发生方向混淆：

PHY TX：PHY → MAC，对应 MAC RX；
PHY RX：MAC → PHY，对应 MAC TX。

3. RTL8211F 会真的读取 `phy-mode`

rtl8211f_config_init() 位于：

1	firefly_rk3588_SDK/kernel/drivers/net/phy/realtek.c:181

函数按 phydev->interface 选择：

RGMII：PHY 不加 delay；
RGMII_RXID：PHY 加 RX delay；
RGMII_TXID：PHY 加 TX delay；
RGMII_ID：PHY 两边都加。

所以 phy-mode 不是一个只供 MAC 参考的标签，它会改变 RTL8211F 私有寄存器。

4. RK3588 自己也能加 delay

RK3588 专用代码位于：

1	firefly_rk3588_SDK/kernel/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c:1881-2018

rk3588_set_to_rgmii() 会：

选择 GMAC0/1 的 RGMII mux；
配置 RGMII clock mode；
打开或关闭 SoC 侧 TX/RX delay；
写入 tx_delay/rx_delay tap。

Firefly 示例选择 rgmii-rxid，PHY 负责 RX delay，DTS 又给 SoC 配 tx_delay = <0x42>。这是一种明确分工，而不是“两个地方都随便填一个值”。

5. RGMII 时序问题的典型症状

10/100 Mbps 正常，1000 Mbps 不稳定；
ping 小包正常，iperf3 大流量丢包；
单向正常、反向异常；
ethtool -S 中 CRC、alignment、receive error 增长；
不同温度、不同线缆或不同对端表现不一致。

调试时不要问“delay 应该填多大”，而要先问：

原理图和 PCB 由哪一侧提供 skew？
PHY internal delay 开了哪一边？
SoC internal delay 开了哪一边？
最终 DTB 的配置是否和设想一致？
经过双向压力测试后，稳定窗口在哪里？

五、probe：把一个 DWMAC IP 注册成 Linux 网卡

1. 从 compatible 进入 `rk_gmac_probe()`

RK3588 match 表在 dwmac-rk.c:2879-2940，其中：

1	{ .compatible = "rockchip,rk3588-gmac", .data = &rk3588_ops },

platform driver 的 probe 是 rk_gmac_probe()，位于 dwmac-rk.c:2774。

它的主干是：

rk_gmac_probe()
  → stmmac_get_platform_resources()
  → stmmac_probe_config_dt()
  → rk_gmac_setup()
  → rk_gmac_clk_init()
  → rk_gmac_powerup()
  → stmmac_dvr_probe()

2. 平台层准备什么

stmmac_get_platform_resources() 取得：

MMIO resource；
macirq；
可选 wake/LPI IRQ。

stmmac_probe_config_dt() 解析：

MAC 地址；
phy-mode 和 phy-handle；
MDIO 子节点；
FIFO/ring/queue 参数；
DMA burst；
TSO、RSS 等能力；
AXI/MTL 队列配置。

Rockchip 私有路径再取得 GRF/PHP_GRF、clock、reset、power 和 delay 属性。

3. `rk3588_ops` 是 SoC 差异接口

rk3588_ops
  ├─ set_to_rgmii
  ├─ set_to_rmii
  ├─ set_rgmii_speed
  ├─ set_rmii_speed
  └─ set_clock_selection

链路速度变化时，stmmac 会经平台 fix_mac_speed 回调进入 rk3588_set_gmac_speed()：

链路速率	RGMII clock divider
1000 Mbps	DIV1
100 Mbps	DIV5
10 Mbps	DIV50

PHY 协商到 1 Gbps 后，如果 SoC clock 仍停留在百兆分频，link 灯可以亮，数据仍然无法正确传输。

4. `stmmac_dvr_probe()` 创建 Linux netdev

通用 probe 位于 stmmac_main.c:5061-5332，主要完成：

devm_alloc_etherdev_mqs()；
初始化 stmmac_priv 与多队列；
识别 DWMAC 版本和硬件 feature；
创建 phylink；
注册每个 channel 的 RX/TX NAPI；
安装 netdev ops 和 ethtool ops；
register_netdev()。

probe 成功只代表接口被内核管理。真正启动 ring、DMA 和 PHY 要等 ip link set ethX up 调用 ndo_open。

5. `net_device_ops` 是阅读入口

stmmac_netdev_ops 位于 stmmac_main.c:4789-4822，最关键的三个回调是：

1
2
3

ndo_open       → stmmac_open
ndo_start_xmit → stmmac_xmit
ndo_stop       → stmmac_release

如果要系统学习任意 Linux 网卡驱动，先找到这三个入口，再找 IRQ/NAPI 注册位置，通常就能搭起主骨架。

六、MDIO、PHY ID 与 RTL8211F 驱动绑定

1. stmmac 注册一个 `mii_bus`

MDIO 实现在 stmmac_mdio.c：

stmmac_mdio_read()      :222
stmmac_mdio_write()     :289
stmmac_mdio_reset()     :354
stmmac_mdio_register()  :406

stmmac_mdio_register() 创建 mii_bus，把 read/write/reset 回调指向 DWMAC MDIO controller，然后由 phylib 枚举 PHY。

2. DTS `reg` 必须与 strap 地址一致

1	phy@1 { reg = <1>; };

地址通常由 PHY strap 电阻决定。DTS 写 1、硬件实际 strap 为 0 时，常见现象是：

MDC 有时钟；
MDIO 读回 0xffff 或 0x0000；
/sys/bus/mdio_bus/devices/ 没有期望设备；
open 报找不到 PHY。

3. phylib 用真实 PHY ID 匹配 Realtek driver

RTL8211F 的 PHY ID 是 0x001cc916。驱动表位于 realtek.c:691-700，安装：

rtl8211f_config_init()；
rtl8211f_ack_interrupt()；
rtl8211f_config_intr()；
genphy suspend 与 Realtek resume；
paged register access。

板级 DTS 使用通用的：

1	compatible = "ethernet-phy-ieee802.3-c22";

并不妨碍匹配 Realtek driver，因为最终依据是 MDIO 读出的 PHY ID。

4. PHY IRQ 和 MAC IRQ 完全不同

RTL8211F 的 link interrupt enable/ack 位于 realtek.c:93-150。这个中断只用于通知 PHY 链路状态变化。

MAC/DMA IRQ 则通知：

RX descriptor 已完成；
TX completion；
DMA error；
MAC/MTL/LPI/PTP 事件。

把 PHY IRQ 配错，通常影响 link 变化检测；把 MAC IRQ 配错，数据路径会停止。两者不能混为一谈。

七、phylink：link up 时到底谁配置谁

stmmac_init_phy() 位于 stmmac_main.c:1145，优先通过：

1	phylink_of_phy_connect()

按 phy-handle 连接 PHY。如果没有标准 handle，则尝试从 MDIO bus 按地址连接。

stmmac 提供的 phylink MAC ops 位于 stmmac_main.c:865-1110：

stmmac_validate()：限制 MAC 支持的接口和速率；
stmmac_mac_config()：配置接口状态；
stmmac_mac_link_down()：关闭 MAC TX/RX；
stmmac_mac_link_up()：配置 speed/duplex/pause，并通知平台改速率。

完整链路是：

网线插入
→ RTL8211F 自动协商
→ PHY IRQ 或 phylib delayed work
→ 读取 link/speed/duplex/pause
→ phylink resolve
→ stmmac_mac_link_up()
→ rk_fix_speed()
→ rk3588_set_gmac_speed()
→ MAC 按协商结果工作

phylib 的 phy_state_machine() 位于 drivers/net/phy/phy.c:1197，它运行在 delayed work 上下文，可以执行 MDIO 事务；这与收包的 hardirq/NAPI 路径是两套不同上下文。

八、open：什么时候 ring、IRQ 和 DMA 真正开始工作

stmmac_open() 位于 stmmac_main.c:2901。将接口置为 UP 后，典型流程是：

stmmac_open()
  ├─ stmmac_init_phy()
  ├─ 分配 descriptor ring 和 RX buffer
  ├─ stmmac_hw_setup()
  ├─ request_irq()
  ├─ napi_enable()
  ├─ 启动 DMA RX/TX
  ├─ phylink_start()
  └─ netif_tx_start_all_queues()

其中 stmmac_hw_setup() 位于 stmmac_main.c:2753-2898，负责把软件配置落到硬件：

DMA reset 和 channel 初始化；
descriptor base/tail；
MAC core 与 packet filter；
RX/TX queue 和 DMA channel 映射；
MTL scheduling；
checksum、TSO、RSS、CBS；
中断合并；
PTP 与 EEE。

顺序非常重要：ring 未完成前不能启动 DMA；NAPI 未 enable 前不应开放 RX 中断；关闭路径也必须按相反方向阻止新工作后再释放 DMA memory。

九、TX：一个 skb 如何变成网线上的帧

1. 调用链

send()/sendmsg()
→ TCP/UDP/IP
→ qdisc
→ dev_hard_start_xmit()
→ stmmac_xmit()
→ TX descriptor ring
→ GMAC DMA 读取 DDR
→ MAC/MTL
→ RGMII
→ RTL8211F
→ 网线

stmmac_xmit() 位于 stmmac_main.c:3468。

2. `ndo_start_xmit` 必须完成什么

根据 skb->queue_mapping 选 TX queue；
计算 linear data 和 frags 需要多少 descriptor；
检查 ring 空间，不足则停止 netdev queue；
处理 checksum、TSO、VLAN 和 timestamp metadata；
用 DMA API 映射 skb 数据；
写 descriptor 地址、长度、first/last segment；
保存 descriptor 到 skb/DMA mapping 的软件关系；
用内存屏障保证描述符字段先发布；
设置 OWN，把 descriptor 交给 DMA；
更新 tail pointer/doorbell。

3. TX completion 不是可选项

DMA 完成发送后，TX NAPI 调用 stmmac_tx_clean()，入口在 stmmac_main.c:2087：

检查 descriptor 已归 CPU；
解析发送错误；
dma_unmap_*()；
释放 skb；
更新统计；
ring 空间恢复后唤醒 queue。

TX 所有权变化可以概括为：

协议栈拥有 skb
→ ndo_start_xmit 接管 skb
→ DMA 拥有 descriptor 和读取 buffer 的权利
→ completion 将 descriptor 归还 CPU
→ TX clean 解除 mapping 并释放 skb

如果 ndo_start_xmit 返回 NETDEV_TX_OK，驱动已经消费 skb；如果返回 NETDEV_TX_BUSY，驱动不能偷偷释放或修改 skb。

4. 常见 TX bug

descriptor 数量估算不足；
DMA map 失败后回滚不完整；
OWN 设置过早，设备读到半写 descriptor；
忘记更新 tail pointer；
completion 漏掉 unmap/free；
queue stop 后没有 wake；
close 时 DMA 仍访问已释放 ring。

十、RX：DMA buffer 如何变成 skb

1. 调用链

网线
→ RTL8211F
→ RGMII
→ GMAC MAC/MTL
→ DMA 写 RX buffer
→ RX IRQ
→ NAPI poll
→ stmmac_rx()
→ 构造 skb 与 metadata
→ napi_gro_receive()
→ IP/TCP/UDP/socket

2. RX 先有 buffer，后有数据

驱动必须提前为 RX ring 准备 buffer：

分配 page
→ DMA map
→ 把 DMA address 写进 RX descriptor
→ 设置 OWN
→ DMA 可向该 buffer 写包

如果 refill 断掉，网口可能在启动时收几个包，耗尽 ring 后完全停止。

3. `stmmac_rx()` 的核心职责

stmmac_rx() 位于 stmmac_main.c:3862-4069，它会：

检查 descriptor ownership；
解析 first/last segment、长度和错误；
做 DMA sync；
构造 skb linear area 和 frags；
处理 checksum、VLAN、RSS hash、timestamp；
调用 eth_type_trans() 设置协议和 MAC header 语义；
记录来源 RX queue；
调用 napi_gro_receive()；
保存跨 descriptor 或跨 budget 的半包状态；
refill 新 buffer。

关键提交点在：

1
2
3

stmmac_main.c:4048  skb_record_rx_queue()
stmmac_main.c:4049  napi_gro_receive()
stmmac_main.c:4064  stmmac_rx_refill()

调用 napi_gro_receive() 后，skb 所有权已交给 GRO/协议栈，驱动不能继续访问或释放它。

4. page 所有权比 skb 更容易出错

RX 中必须区分两种情况：

数据被 copy 到 skb linear head：原 RX page 可较早回收；
page 被挂到 skb frag：page 生命周期转交 skb。

如果已经挂入 frag 的 page 又立即 refill 给 DMA，设备可能覆盖协议栈仍在读取的数据，造成 use-after-free、数据随机损坏或难以复现的 checksum error。

十一、IRQ 与 NAPI：为什么中断里不直接把包收完

stmmac 主 ISR 是 stmmac_interrupt()，位于 stmmac_main.c:4254-4307。它负责：

检查设备是否 DOWN；
读取 MAC/MTL 状态；
处理 LPI、PCS、安全特性等事件；
进入 DMA interrupt handler；
对活跃 channel 屏蔽 IRQ 并调度 NAPI。

RX/TX NAPI 入口分别是：

1 2	stmmac_napi_poll_rx() stmmac_main.c:4071 stmmac_napi_poll_tx() stmmac_main.c:4093

NAPI 的设计目标不是“减少一次函数调用”，而是避免高包速率下每个包都打断 CPU：

第一个包触发 IRQ
→ 驱动 mask 当前队列 IRQ
→ NAPI 在 softirq 中批量处理多个包/completion
→ work_done < budget 时 complete
→ 驱动重新打开 IRQ

执行上下文必须分清

路径	上下文	能否睡眠
probe/open/close/PM	进程上下文	可以
`ndo_start_xmit`	网络发送 softirq 上下文	不可以
MAC ISR	hardirq	不可以
NAPI poll	NET_RX softirq	不可以
PHY state machine	workqueue	可以

因此：

hardirq 中不能做长时间 MDIO；
NAPI 中不能调用可能睡眠的 clock/regulator API；
open/close 要和 IRQ、NAPI、DMA 并发退出同步；
IRQ/NAPI 共享短状态时通常使用 spinlock；
PHY paged register 应走 phylib 的锁与 helper。

十二、DMA 驱动最核心的不是寄存器，而是所有权

理解网卡驱动时，建议始终追踪三套 owner：

descriptor 属于 CPU 还是 DMA；
DMA buffer/page 属于 ring、DMA、驱动还是 skb；
skb 属于协议栈、qdisc、驱动还是 GRO/socket。

1. TX 所有权

时点	skb	descriptor	mapping
进入 xmit	驱动接管	CPU	建立中
发布 descriptor	驱动保留回收责任	DMA	DMA 可读
completion	待释放	CPU	待 unmap
clean 完成	已释放	free	已解除

2. RX 所有权

时点	page/buffer	descriptor	skb
refill	DMA/ring	DMA	无
DMA 写完	驱动	CPU	无
构造 skb	驱动或 skb	CPU	驱动
GRO 提交	skb/协议栈	待 refill	协议栈

3. 为什么需要屏障

CPU 写 descriptor 的普通字段后，必须保证设备先看见地址和长度，再看见 OWN：

write address/length/control
→ dma_wmb()
→ set OWN
→ write tail/doorbell

这不是编译器风格问题，而是 CPU、互连、cache 和 DMA 对内存观察顺序的问题。

4. 为什么不能绕过 DMA API

即使 arm64 平台常见 cache coherent，DMA API 仍负责：

DMA address translation；
IOMMU；
DMA mask；
mapping 生命周期；
非一致性平台的 cache sync。

把 CPU virtual address 直接写到 descriptor，是不可移植也不可靠的。

十三、一个网卡驱动还要照顾哪些“非收发”能力

一个可用于产品的驱动不能只实现 ping：

MAC 地址管理和 RX filter；
MTU 与 jumbo frame；
multicast/promiscuous；
checksum offload；
scatter-gather、GSO/TSO；
VLAN insert/strip/filter；
RSS 与多队列；
interrupt coalescing；
ethtool feature/statistics/ring/coalesce；
PTP hardware timestamp；
EEE/LPI；
WoL；
tc/CBS；
TX timeout 和 DMA error recovery；
system/runtime suspend/resume。

RK3588 DTS 的 DWMAC 节点声明了 snps,tso。如果怀疑 offload 路径，可以先用最小配置缩小范围：

1 2	ethtool -k eth0 ethtool -K eth0 rx off tx off tso off gro off gso off

如果关闭某项后恢复正常，下一步应检查 descriptor bit、skb metadata、MTU/frags 和 feature advertisement，而不是永久关闭功能后结束分析。

十四、关闭与挂起：先阻止新工作，再释放资源

stmmac_release() 位于 stmmac_main.c:3060。关闭路径的核心顺序是：

停止 TX queue
→ 停止 phylink/PHY
→ mask/disable IRQ
→ napi_disable() 并等待 poll 退出
→ stop DMA TX/RX
→ free IRQ
→ unmap/free packet buffer 和 descriptor

最危险的错误是先释放 ring，后停止 DMA。此时设备仍可能按旧 DMA address 写内存。

RK3588 的 PM 包装位于 dwmac-rk.c:2848-2877：

不需要 WoL 时，suspend 会关闭 Rockchip GMAC 电源/时钟；
需要 WoL 时，必须保留足够的 PHY、MAC 和唤醒 IRQ 资源；
resume 先恢复平台资源，再恢复 stmmac。

WoL 经常跨越 PHY 电源、MAC wake IRQ、clock domain、pinctrl sleep state 和系统电源策略，不能只看一个 ethtool -s wol g。

十五、故障定位：先判断坏在哪一层

场景 1：驱动没有 probe

1 2	dmesg \| grep -Ei 'stmmac\|dwmac\|gmac\|ethernet' ls -l /sys/bus/platform/drivers/rk_gmac-dwmac/

检查：

最终 DT 节点是否 okay；
compatible 是否正确；
clock/reset/power-domain；
pinctrl 冲突；
内核配置。

本地 BSP .config 中已启用：

CONFIG_STMMAC_ETH=y
CONFIG_STMMAC_PLATFORM=y
CONFIG_DWMAC_ROCKCHIP=y
CONFIG_PHYLINK=y
CONFIG_REALTEK_PHY=y

场景 2：probe 成功，但找不到 PHY

1 2	dmesg \| grep -Ei 'mdio\|phy\|no phy\|attached PHY' ls /sys/bus/mdio_bus/devices/

检查：

MDC/MDIO pinmux；
PHY 电源；
reset GPIO 与延时；
strap 地址与 DTS reg；
读取 ID 是否为 0x001cc916。

场景 3：PHY 存在，但 no link

1 2	ethtool eth0 cat /sys/class/net/eth0/carrier

优先检查：线缆、网络变压器、PHY 模拟供电、晶振、自动协商、PHY reset 和对端能力。此时 DMA ring 通常还不是首要矛盾。

场景 4：link up，但 ping 不通

ip -s link show eth0
ethtool -S eth0
cat /proc/interrupts | grep -Ei 'eth|gmac'
tcpdump -ni eth0 -e

分层判断：

没有 RX IRQ：看 RGMII、pinmux、clock、MAC enable；
有 IRQ、无 RX packet：看 descriptor ownership、NAPI、RX buffer；
CRC/error 增长：看 RGMII delay 与信号完整性；
ARP 可以、大包不行：看 MTU、checksum、TSO、DMA/cache；
单向不通：分别检查 TX 与 RX 时序。

场景 5：百兆正常、千兆异常

优先级通常是：

RGMII delay 重复或缺失；
link up 后 RK3588 clock divider 没切换；
125 MHz clock；
PCB 等长和信号完整性；
PHY 供电、变压器和四对线；
对端兼容性。

可短暂强制百兆做对照：

1
2
3

ethtool -s eth0 speed 100 duplex full autoneg off
# 测试完成后恢复
ethtool -s eth0 autoneg on

场景 6：高负载丢包、hang 或 TX timeout

ethtool -S eth0
cat /proc/net/softnet_stat
cat /proc/interrupts | grep -Ei 'eth|gmac'
mpstat -P ALL 1
iperf3 -c  -P 4 -t 300
iperf3 -c  -R -P 4 -t 300

重点检查：

RX missed/overflow、buffer unavailable；
NAPI budget 和 softnet backlog；
IRQ affinity、RPS/XPS；
ring size、coalescing；
RX refill；
TX queue stop/wake；
DMA mapping/IOMMU error；
温度、clock 和电源管理。

十六、推荐的真实开发板 bring-up 路线

第一步：静态硬件闭环

原理图确认 GMAC0/GMAC1；
PHY 型号、strap 地址、reset、IRQ、clock source；
RGMII delay 由 PCB、PHY、SoC 哪一方承担；
DTS status、pinmux、phy-mode、delay、phy-handle；
Kconfig。

第二步：只验证控制面

platform probe；
clock/reset/power；
MDIO 稳定读取 PHY ID；
ethtool 能显示 PHY 能力。

第三步：验证链路状态机

10/100/1000 自动协商；
网线插拔 carrier 变化；
speed change 时 SoC 分频变化；
PHY IRQ 或轮询稳定。

第四步：最小数据路径

ARP、ping；
临时关闭复杂 offload；
观察 RX/TX packets、IRQ、NAPI、DMA error。

第五步：性能、温度和电源回归

单向与双向 iperf3；
小包、大包、并发流；
长时间压力；
suspend/resume；
网线热插拔和对端速率变化；
逐项恢复 offload。

QEMU virt 无法真实模拟 RK3588 GRF、RGMII 时序、外置 RTL8211F、变压器和板级信号完整性。这类问题可以在 QEMU 中学习通用网络栈，却必须在真实开发板上完成最终验证。

十七、源码阅读地图

如果希望沿本文继续读代码，推荐按这个顺序：

rk3588.dtsi:690、rk3588s.dtsi:5500：SoC 资源；
rk3588-firefly-port.dtsi:179：板级 RGMII 与 PHY；
dwmac-rk.c:1881-2018：RK3588 interface/clock/delay；
dwmac-rk.c:2774：平台 probe；
stmmac_main.c:5061：通用 probe；
stmmac_main.c:4789：netdev ops；
stmmac_main.c:2901：open；
stmmac_main.c:3468：TX；
stmmac_main.c:4254 与 :4071：IRQ/NAPI；
stmmac_main.c:3862：RX；
stmmac_mdio.c:406：MDIO bus；
stmmac_main.c:865-1110：phylink MAC callbacks；
realtek.c:181：RTL8211F internal delay；
drivers/net/phy/phy.c:1197：PHY 状态机。

把这些入口串起来后，一个 SoC 网卡驱动的全景就会从“很多不相关的文件”变成四条清晰主线：

板级资源线：DTS → dwmac-rk → clock/reset/GRF/delay
链路控制线：MDIO → phylib → RTL8211F → phylink → MAC link up
发送数据线：skb → stmmac_xmit → TX DMA → TX clean
接收数据线：RX DMA → IRQ → NAPI → stmmac_rx → GRO → 协议栈

小结

RK3588 + RTL8211F 网卡驱动最值得掌握的，不是某个寄存器魔数，而是分层边界和状态闭环：

MAC 与 PHY 是两个硬件世界，RGMII 传数据，MDIO 做管理；
dwmac-rk 解决 SoC 接入问题，stmmac 解决通用 MAC/DMA 数据路径；
phylink 协调 MAC 与 PHY，Realtek driver 只实现 RTL8211F 差异；
probe 与 open 不同：前者注册设备，后者才启动 ring、IRQ、DMA 和 PHY；
IRQ 只负责快速调度，NAPI 批量处理数据；
TX/RX 的核心是不丢失 descriptor、DMA mapping、page 和 skb 的所有权；
RGMII delay 是板级时序设计，不是可以盲目复制的经验值；
排错要先判断层次：probe、MDIO、PHY link、RGMII、DMA/NAPI、协议栈，不能看到 link up 就跳过中间所有环节。

一旦用这套模型分析问题，link up but no traffic、100M works but 1G fails、RX stops after seconds 这类现象就不再是随机故障，而会变成可以逐层收集证据、逐层排除的工程问题。

Linux sk_buff 深度解析（八）：Socket 内存、零拷贝、丢包与版本演进

2026-07-15T00:00:00.000Z

写在前面

sk_buff 是 Linux 网络栈最核心、也最容易被误解的数据结构之一。它并不是“装着一个完整网络包的结构体”，而是贯穿驱动、协议栈、队列、Socket、Netfilter、tc、BPF 与硬件 offload 的控制对象和所有权载体。

从 socket truesize/owner、MSG_ZEROCOPY、error queue、drop reason 讲到 Linux 5.10 与 6.1 的 skb 演进，并总结 RK3588 BSP 的验证边界。

本文以本地 Linux 5.10.209 源码为主线；涉及演进时对照 Linux 6.1.99，涉及网卡驱动时结合 Firefly RK3588 SDK Linux 5.10.198。本文是源码分析，不把尚未执行的 QEMU、tracepoint 或开发板实验写成已验证结论。

阅读前先建立四个问题

阅读任何 skb 代码路径，都建议反复追问：

当前 skb->data 指向哪一层协议头，linear 与 non-linear 数据分别在哪里？
哪些字段刚被修改，下一层为什么依赖这些字段？
当前谁持有 skb shell、head、frag page 以及 socket/dst/conntrack 等外部引用？
成功、失败、重试、redirect 和丢弃分支分别由谁消费或释放 skb？

本篇核心结论

socket 用 truesize 而不是 wire length 计量 skb 占用，并通过 destructor 归还记账。
MSG_ZEROCOPY 主要避免 payload copy；user page、ubuf_info、segment 和 error queue 形成额外生命周期。
6.1 的重点是 hot-path cache、page_pool recycle、multi-buffer XDP 和结构化丢包原因。
RK3588 BSP 必须区分通用 skb 语义、stmmac 实现和真实硬件能力，静态分析不能替代实机验证。

1. Socket 内存计量与 MSG_ZEROCOPY

结论摘要

socket 使用 skb truesize 进行收发内存记账，owner helper 把 sk 和 destructor 绑定到 skb。skb_orphan() 解除 socket owner 并执行 destructor。MSG_ZEROCOPY 不等于完全不复制所有 header，而是让 TX payload 引用用户页，通过 ubuf_info 跟踪 pinned pages；skb clone/segment/completion 共同持有该引用，最终通过 error queue 通知用户可重用内存。

一、接收内存

skb_set_owner_r(skb, sk) 定义于 kernel-5.10/include/net/sock.h:2281。典型动作：

设置 skb->sk；
设置 destructor=sock_rfree；
按 skb->truesize 增加 sk_rmem_alloc。

最终释放调用 sock_rfree() 归还计量并唤醒/更新 socket 状态。

为什么不用 len：一个 64 字节包可能占用 skb slab、head allocation、page、frag 和对齐开销，真实内存远大于 wire length。

二、发送内存

skb_set_owner_w() 位于 kernel-5.10/net/core/sock.c:2091，通常：

绑定 sk；
设置 destructor=sock_wfree；
增加 sk_wmem_alloc；
关联 socket ref/lifetime。

TCP write/retransmit queue 长期持有 skb，发送内存只有在 ACK/释放相应 skb 引用后才真正归还；网卡 completion 与 TCP ACK 的生命周期层次不同。

三、skb_orphan

skb_orphan() 位于 kernel-5.10/include/linux/skbuff.h:2811，用于清除 socket owner：

若有 destructor，调用它归还 rmem/wmem 或其它 owner 状态；
skb->sk=NULL；
destructor=NULL。

常见于转发、进入设备、某些 clone/重传或需要解除 socket lifetime 的路径。orphan 不是释放 packet data，skb 仍然存在。

错误地 orphan 太早会让 socket accounting 过早下降；太晚会让 skb 不必要地持有 socket 引用。

四、MSG_ZEROCOPY 目标

用户发送大 payload 时，普通路径从用户空间复制到 kernel skb/page。MSG_ZEROCOPY 尝试：

pin 用户页；
把 page fragment 引用挂入 skb；
header 仍可在 kernel linear head 中构造；
DMA 直接读取用户页；
完成后异步通知用户。

因此是 payload zerocopy，不保证系统调用、协议头、分段和所有元数据都零成本。

五、ubuf_info

struct ubuf_info 记录：

completion callback；
refcount；
zerocopy success 状态；
用户页 accounting；
ID/range 等通知信息。

skb shared info 的 destructor_arg 指向 ubuf_info，tx_flags 标记 SKBTX_DEV_ZEROCOPY/相关状态。定义见 kernel-5.10/include/linux/skbuff.h:466，相关 helper 见 kernel-5.10/include/linux/skbuff.h:1471-1519。

六、clone、GSO 与 zerocopy ref

一个用户 buffer 可能经过：

大 skb；
GSO segment 多个 skb；
retransmit clone；
设备发送副本。

每个仍可能访问用户页的对象必须持有 ubuf/page 引用。最后一个完成前不能通知用户复用内存。

skb_zcopy_set/clear、clone/copy/segment 路径维护 ubuf_info。某个 segment fallback copy 后，可更新 overall zerocopy success，但仍需等待其它引用。

七、completion 与 error queue

TX completion 或协议确认最终调用 zerocopy callback；通知排队入口见 kernel-5.10/net/core/skbuff.c:4602。通知通常作为 extended error skb 放入 socket error queue：

completion
→ build notification skb
→ sock_queue_err_skb()
→ poll/recvmsg(MSG_ERRQUEUE)
→ user receives completed ID range

error queue 中“error”不一定表示发送失败，也用于 timestamp、zerocopy completion、Wi-Fi ACK 等异步状态。

八、失败与 fallback

pin 超过 memlock/accounting：返回错误或 fallback copy；
设备不支持 SG：软件复制/linearize；
加密/协议修改要求可写：部分 copy；
DMA map 失败：释放当前 refs，通知失败；
clone/segment 中途失败：已创建对象和 ubuf refs 必须回滚；
socket close：仍需等待/清理 outstanding completion。

用户必须在收到 completion 前保持 buffer 不修改/不复用。

九、truesize 与 zerocopy

zerocopy payload page 仍占系统资源：

pinned user pages；
skb shell/head；
page refs；
DMA mappings；
retransmit/queue 生命周期。

内存 accounting 不能因为“没有 memcpy”就忽略。不同路径可能同时使用 socket wmem、locked_vm、ubuf refs 和 device queue accounting。

十、所有权表

对象	owner/ref	释放/完成
skb shell	users	consume/kfree
kernel head	dataref	skb release data
user page	pin/page ref	ubuf final completion
ubuf_info	callback refcount	last skb/segment complete
socket wmem	destructor/truesize	sock_wfree/orphan
notification skb	error queue	user recvmsg/free

十一、常见误区

MSG_ZEROCOPY 不代表完全没有 CPU copy 或协议头分配。
网卡 completion 后用户页不一定立即可复用，可能还有 clone/segment/retransmit 引用。
error queue 不只传错误。
orphan 不释放 skb 数据，只解除 owner/destructor。
truesize 仍然重要，zerocopy 不是免费内存。
users、dataref、page pin、ubuf ref 和 socket wmem 是不同计数。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`sk/destructor/truesize`	owner helper	destructor 归还 rmem/wmem 和记账引用
`destructor_arg/tx_flags`	zerocopy helper	skb/shared info 持有 ubuf_info
user page pin/ref	MSG_ZEROCOPY	最后一个 completion 前用户不得复用

最小调用链

sendmsg(MSG_ZEROCOPY)
→ pin user pages/创建 ubuf_info
→ skb/GSO segments 持有引用
→ TX completion/协议释放
→ error queue 通知可复用范围

2. 从 kfree_skb 到结构化 drop reason

结论摘要

释放 skb 不等于发生丢包：正常 TX completion、用户读取和协议消费也会释放。Linux 5.10 主要通过 kfree_skb tracepoint 记录释放位置，难以表达语义原因；Linux 6.1 的 kfree_skb_reason() 和 enum skb_drop_reason 让调用者携带结构化原因，tracepoint 同时记录 location、protocol 和 reason，从而区分 backlog 满、checksum、header、socket filter、route 等类别。

一、正常消费与丢弃

consume_skb()：正常路径消费完成；
napi_consume_skb()：NAPI/TX completion 正常消费并优化回收；
kfree_skb()：传统上常用于 drop/error，但也存在历史调用不够严格的情况。

内存结果可能相同，观测语义不同。分析 drop 不能只统计所有 skb free。

二、Linux 5.10 trace_kfree_skb

kfree_skb() 位于 kernel-5.10/net/core/skbuff.c:705，在真正释放前调用：

1	trace_kfree_skb(skb, __builtin_return_address(0));

tracepoint 定义于 kernel-5.10/include/trace/events/skb.h。可看到：

skb 地址；
location/调用地址；
protocol 等有限字段。

主要局限：

location 需要符号化；
同一 helper 可能因多个条件 drop；
wrapper 后 location 不够接近根因；
没有统一 reason taxonomy；
正常/异常历史调用混杂。

三、Linux 6.1 drop reason

enum skb_drop_reason 定义于 kernel-6.1/include/net/dropreason.h:78。kfree_skb_reason() 位于 kernel-6.1/net/core/skbuff.c:885。

调用者：

1	kfree_skb_reason(skb, SKB_DROP_REASON_...);

tracepoint 记录 reason。普通 kfree_skb() 可映射为 NOT_SPECIFIED，便于逐步迁移旧调用点。

四、reason 分类

枚举覆盖的类型随版本演进，典型类别：

NOT_SPECIFIED；
NO_SOCKET / SOCKET_FILTER；
PKT_TOO_SMALL / TCP_CSUM / UDP_CSUM；
NETFILTER_DROP；
IP_INHDR / IPV6_BAD_EXTHDR；
NO_ROUTE；
CPU_BACKLOG；
FULL_RING / QDISC_DROP；
XFRM_POLICY；
PROTO_MEM；
TCP_* 状态原因。

reason 应描述最接近根因的逻辑，而不是简单写“调用了 kfree”。

五、reason 传递

深层 helper 发现错误时可能：

返回 enum reason 给上层；
通过输出参数设置 reason；
上层统一释放并 trace；
skb list/segment 释放对每个成员传播同一 reason。

好处是把“判断原因”和“真正释放地点”分开后仍保留根因。

六、CPU backlog 示例

RPS enqueue 时目标 CPU 队列达到上限，5.10 通常只能从 enqueue_to_backlog() 的 kfree location 推断。6.1 可标记 SKB_DROP_REASON_CPU_BACKLOG，更直接区分：

驱动 ring drop；
qdisc drop；
socket rcvbuf drop；
softnet backlog drop。

七、协议与 reason

tracepoint 还可记录 skb->protocol，但 protocol 字段在不同层可能：

尚未设置；
为 outer protocol；
VLAN/隧道后变化；
非 Ethernet skb。

reason 与 location 仍需结合调用链、设备和协议字段解释，不能单独作为完整诊断。

八、释放链与 trace 时机

reason trace 在 users 归零并即将释放时触发。若 skb 仍有 users，当前调用只减引用，不一定产生最终 free trace。clone 共享 data 的最后一个 shell/dataref 释放时机也不同。

因此 trace 数量不等于收到包数或 drop packet 数，需要理解 clone/list/segment。

九、设计价值

统一 drop taxonomy；
eBPF/perf/drop monitor 可按 reason 聚合；
减少依赖调用地址和版本行号；
支持协议逐步细化；
让生产环境统计更可读；
区分资源压力、策略、安全校验和协议错误。

十、常见误区

所有 kfree_skb 都算丢包是错误的。
reason 不是 errno，二者服务不同层次。
NOT_SPECIFIED 不代表正常，只表示调用点尚未细化。
clone 的 free event 不能简单按一个 event=一个 wire packet。
reason 仍需结合 location/dev/protocol/调用链。
5.10 没有 reason 枚举时仍可用 location 和协议统计，但准确性较弱。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
skb pointer	free/consume/drop helper	调用后原持有者不得再访问
drop reason	`kfree_skb_reason()`	结构化原因随 tracepoint 暴露
location/protocol	旧式 tracepoint	只能辅助定位，不能替代原因语义

3. Linux 5.10 到 6.1 的关键演进

结论摘要

5.10 到 6.1 的 skb 演进重点不是四指针模型改变，而是高性能内存回收、多 buffer XDP、GRO 分桶和丢包可观测性加强。6.1 用 NAPI skb cache bulk 操作降低 shell slab 开销，用 pp_recycle 把 page_pool 回收信息带入 skb free，用 multi-buffer XDP 对接 shared info，用结构化 drop reason 替代仅靠 location 的诊断。

一、基础模型保持稳定

两版仍保持：

skb shell 与 head 分离；
head/data/tail/end；
shared info 位于 end；
len/data_len/truesize；
frags/frag_list；
users/dataref/page ref；
clone/copy/COW/free 分层。

因此 5.10 是理解核心机制的可靠基线。

二、NAPI skb shell cache

6.1：

napi_skb_cache_get()：kernel-6.1/net/core/skbuff.c:252；
napi_skb_cache_put()：kernel-6.1/net/core/skbuff.c:1054。

per-CPU cache 配合 kmem_cache_alloc_bulk/free_bulk：

一次从 slab 获取/归还多个 skb shell；
NAPI hot path 从本地数组 pop/push；
降低 allocator lock、freelist 和 cacheline 成本；
适合高 PPS 小包。

5.10 已有 NAPI 分配/延迟回收思想，但 6.1 的 bulk cache 路径更系统。

三、pp_recycle 与 page_pool

6.1 struct sk_buff 增加/使用：

1	pp_recycle:1

位置：kernel-6.1/include/linux/skbuff.h:926。

释放 head/frag 时：

pp_recycle set
→ page_pool_return_skb_page(page)
  ├─ page 属于合适 page_pool：直接回池
  └─ 不能回池：普通 put_page/free

关键位置：

head recycle：kernel-6.1/net/core/skbuff.c:758；
frag unref：kernel-6.1/net/core/skbuff.c:785；
helper：kernel-6.1/include/linux/skbuff.h:5104；
page_pool API：kernel-6.1/include/net/page_pool.h:242。

5.10 驱动更常显式区分 copy page 直接 recycle 与 frag page 通用释放，跨 clone/协议栈自动回池能力较弱、驱动耦合更高。

四、clone 与 recycle 风险

clone 会复制 pp_recycle，但共享 page/dataref 带来竞态：不能让某个 clone 过早把 page 回池。6.1 在 clone/copy/expand 路径检查 recycle 状态与共享条件，例如 kernel-6.1/net/core/skbuff.c:793-802、kernel-6.1/net/core/skbuff.c:5459-5463。

这说明 recycle flag 不是“free 时无条件放回 pool”，必须与 page ownership/refcount 协同。

五、XDP multi-buffer

6.1：

xdp_buff_has_frags()：include/net/xdp.h:88；
xdp_update_skb_shared_info()：include/net/xdp.h:223。

XDP packet 可由主 buffer + frags 组成。PASS 转 skb 时把 fragment descriptors 写入 shared info，更新 len/data_len/truesize。5.10 native XDP 设计主要围绕单 buffer，jumbo/multi-descriptor 支持受限。

六、GRO 重构与 hash bucket

5.10 GRO 主要在 net/core/dev.c，一个 NAPI 上的候选 list 比较成本随活跃 flow 增长。

6.1：

实现拆到 net/core/gro.c；
GRO_HASH_BUCKETS=8：include/linux/netdevice.h:339；
gro_hash[]：include/linux/netdevice.h:362；
dev_gro_receive()：net/core/gro.c:483。

先按 skb hash 分桶，再进行协议级 same-flow 比较，减少多 flow 场景线性扫描。

七、drop reason

5.10 trace_kfree_skb 主要记录 location。6.1：

enum skb_drop_reason；
kfree_skb_reason()；
tracepoint reason；
协议函数逐步返回具体 reason。

对 backlog、checksum、header、socket、policy 等根因可结构化统计。

八、skb extensions

6.1 extension ID/类型继续增加，例如 SKB_EXT_MCTP：

enum：kernel-6.1/include/linux/skbuff.h:4626；
size table：kernel-6.1/net/core/skbuff.c:4512。

extension 让低频/可选 metadata 不必永久膨胀核心 struct sk_buff，代价是独立分配/引用和 clone/free 管理。

九、API/代码位置变化

阅读跨版本代码时需要注意：

GRO 函数从 dev.c 移到 gro.c；
API 可能增加 reason/recycle 参数；
inline helper 行号和字段布局变化；
驱动 backport 可能只有部分新机制；
同名函数实现细节不一定相同。

不能只用文件名 diff 判断功能有无，应追踪 symbol、config 和调用点。

十、对驱动开发的影响

主题	5.10 常见责任	6.1 改进
skb shell	普通/NAPI alloc/free	bulk per-CPU cache
RX page	驱动显式 recycle 分支	skb free 可 pp_recycle
jumbo XDP	单 buffer 限制明显	multi-buffer metadata
GRO flow list	线性候选较多	hash buckets
drop	location 推断	structured reason
optional metadata	extensions 较少	extension 类型扩展

十一、常见误区

6.1 并没有推翻 skb 基础模型。
pp_recycle 不等于跳过 page ref 安全。
multi-buffer XDP 需要驱动和 BPF/redirect 全链支持，不只是 helper 存在。
GRO 移文件不只是代码整理，还伴随数据结构/分桶演进。
drop reason 的覆盖是渐进式，仍会有 NOT_SPECIFIED。
BSP 5.10 可能 backport 部分 6.x 特性，必须检查本地源码而非仅看版本号。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`pp_recycle`	page_pool skb 路径	free 时可归还 page_pool
NAPI skb cache	alloc/free hot path	per-CPU cache 批量管理 skb shell
drop reason/XDP frags	6.1 新路径	增强可观测性和 multi-buffer 表达

最小调用链

1
2
3

5.10 基线 skb alloc/build/free
→ 6.1 NAPI cache/page_pool recycle/XDP frags/drop reason 路径
→ 对具体 backport/BSP 做符号级核对

4. RK3588 BSP 中的 skb 生命周期

结论摘要

RK3588 BSP 保持 Linux 5.10 skb 核心模型，平台特性主要体现在 stmmac RX/TX、page_pool、DMA descriptor、checksum/hash/offload 和 vendor patch。源码结论必须分为三层：通用 skb 语义、stmmac 驱动实现、RK3588 平台 glue/硬件能力。QEMU virt 不能验证真实 GMAC DMA/page_pool/offload，最终硬件结论需开发板串口、ethtool、抓包和性能实验。

一、版本与源码边界

通用主线学习树：Linux 5.10.209，commit 6c60e1d；
演进树：Linux 6.1.99，commit 5ab5f07；
Firefly BSP：Linux 5.10.198，commit 11a3d9327b6f。

BSP 版本更早，且可能包含 Android KABI、Rockchip/Firefly 和 stmmac backport。判断差异需对具体文件/symbol diff，不能按 5.10.198 数字推断全部能力。

二、通用 skb 机制

BSP 仍使用：

struct sk_buff shell；
独立 head + tail shared info；
linear/frags/frag_list；
users/dataref/page ref；
alloc/build/clone/copy/free；
NAPI/GRO/RPS/qdisc/socket ownership。

因此阶段 0～4、6～21 的通用概念仍适用，行号和 vendor 字段需以 BSP 树重新检索。

三、RK3588 GMAC 软件层次

Rockchip platform glue (dwmac-rk.c)
  → clocks/resets/GRF/PHY mode/delay
stmmac core (stmmac_main.c)
  → netdev/NAPI/RX/TX/ring/page_pool/skb
DMA descriptor ops
  → OWN/status/address/length
GMAC hardware
  → DMA/MTL/MAC/PHY

dwmac-rk.c 不直接定义 skb 核心语义，它配置平台硬件；真正构造/消费 skb 的主路径在 stmmac core。

四、RX 生命周期

page_pool/RX buffer
→ DMA descriptor OWN to hardware
→ frame received, OWN to CPU
→ stmmac_rx()
  ├─ first data copy to napi_alloc_skb linear head
  ├─ later segments skb_add_rx_frag
  ├─ checksum/hash/rx_queue/protocol
  └─ napi_gro_receive
→ GRO/RX core/IP/socket
→ skb free
→ head/frags page release/recycle

关键入口：firefly_rk3588_SDK/kernel/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3862。

BSP 实现的核心特点：

首段 copy 优化 header locality；
后续 page frag 降低 payload copy；
copy page 可直接 recycle；
frag page 生命周期交给 skb；
refill 在 descriptor 重新 OWN 前准备新 page。

五、TX 生命周期

socket/IP/qdisc
→ stmmac_xmit() :3468
  → map linear/frags
  → fill descriptors
  → OWN to DMA
  → BQL sent
→ hardware transmit
→ stmmac_tx_clean() :2087
  → check OWN/status
  → unmap
  → consume skb at packet completion
  → BQL completed
  → wake queue

一个 skb 占多个 descriptor 时，软件通常只在最后 descriptor 关联 skb，确保所有 mapping 完成后再 free。

六、page_pool 适用性

page_pool 为 RX 提供：

page cache/recycle；
DMA mapping 生命周期优化；
NAPI-local fast path；
与 XDP/frag 的 memory model。

BSP 5.10 的回收更多由驱动显式管理。Linux 6.1 pp_recycle 可把回收意图带入通用 skb free。若向 BSP backport，不能只加一个 flag，还需：

page 标识/pool ownership；
clone/copy/expand 安全；
frag unref helper 参数；
head recycle；
驱动 build_skb/page_pool API 对齐。

七、checksum/hash/offload

硬件能力通过 netdev features 和 descriptor status 进入 skb：

RX checksum → ip_summed；
RX hash → hash/l4_hash；
RX queue → queue_mapping；
TX checksum → PARTIAL descriptor flags；
TSO/GSO → MSS/header/descriptor；
VLAN → tag insertion/stripping metadata。

必须同时检查：设备树/平台配置、stmmac capability、DMA feature register、netdev feature negotiation 和实际 descriptor path。

八、RPS/RFS/XPS 与单/多队列

stmmac 驱动可为软件流调度提供 hash 和 RX queue 信息。实际收益取决于：

GMAC queue 数；
RSS 硬件能力和配置；
IRQ affinity；
RPS/XPS maps；
CPU/cluster/NUMA（RK3588 big.LITTLE）；
应用绑核；
GRO 和包长。

源码能确定机制位置，不能仅凭源码宣称某个 mask 在实机性能更好。

九、XDP 能力边界

判断 native XDP 必须在 BSP stmmac 中找到完整闭环：

XDP program attach；
RXQ info/memory model；
RX poll 在 skb 前执行 XDP；
PASS 转 skb；
TX ring；
redirect/flush；
page_pool return。

若缺失，只能依赖 generic XDP。Linux 6.1 multi-buffer helper 不会自动出现在 BSP 5.10，也不能只复制 helper 而忽略驱动/API 链。

十、BSP 差异分析方法

对每个主题执行：

1. rg 找 BSP symbol 和调用点
2. 与 kernel-5.10 同文件/函数 diff
3. git log/blame 查看 vendor/backport 来源
4. 检查 CONFIG、Kconfig、Makefile
5. 检查 DTS 与 platform glue 是否启用硬件能力
6. 区分编译存在、运行启用、硬件实际支持

不要只比较 include/linux/skbuff.h 就判断完整网络能力；驱动、page_pool、net/core/dev、offload 和平台配置必须一起看。

十一、QEMU 与实机边界

QEMU virt 可以验证 arm64 Linux 协议栈、socket、qdisc、Netfilter 等通用机制，但不能真实模拟：

RK3588 GMAC/MTL/DMA descriptor；
Rockchip GRF/clock/delay；
真实 PHY；
stmmac hardware checksum/RSS/TSO；
page_pool 与真实 DMA 性能。

硬件验证最终需要：串口、dmesg、ethtool -k/-S、debugfs、trace、perf、抓包、iperf 和必要的 IRQ/RPS/XPS 配置实验。本轮笔记仅完成源码分析。

十二、通用结论与 BSP 结论

结论	类型
len/data_len、clone/free 引用规则	通用 skb 语义
stmmac 首段 copy + 后续 frag	当前驱动实现
RK3588 时钟/GRF/PHY delay	平台 glue
某 offload 在板上实际有效	需实机验证
6.1 pp_recycle/drop reason	上游版本演进
BSP 是否 backport 某能力	本地源码事实

十三、常见误区

RK3588 BSP 顶层不是单一 Git 仓库，kernel 子仓提交需单独记录。
stmmac 通用代码存在不等于板级能力已启用。
QEMU virt 启动 BSP kernel 不等于模拟真实 GMAC。
5.10 BSP 可能 backport 新机制，也可能缺少上游 5.10.209 修复。
page_pool 存在不等于所有 frag 都能自动 recycle。
源码支持 XDP 配置不等于 native RX path 完整。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
DMA descriptor/page	RK stmmac RX/TX	驱动、page_pool 与 DMA completion 转移所有权
skb offload metadata	stmmac/BSP	硬件能力决定 checksum/hash/GSO 处理
通用 skb refs	内核 core	vendor glue 不改变 users/dataref/page ref 基本规则

最小调用链

RK3588 GMAC descriptor/page_pool
→ stmmac RX 构造 skb
→ 通用协议栈/socket 或转发
→ qdisc/stmmac TX
→ DMA completion 与 page/skb 回收

源码阅读路线

建议不要从 struct sk_buff 声明开始逐字段背诵，而应使用下面的阅读顺序：

先在入口函数确认 skb 是新分配、clone、队列取出还是从驱动 buffer 构造；
沿成功主线记录 data/len/data_len、header offset、checksum、hash、queue mapping 等字段变化；
再回到每个失败分支，确认 skb、page、DMA、socket 和记账引用是否回滚；
最后对照 5.10、6.1 或 BSP 的同名 symbol，区分语义变化、性能优化和 vendor backport。

本篇总结

socket 用 truesize 而不是 wire length 计量 skb 占用，并通过 destructor 归还记账。
MSG_ZEROCOPY 主要避免 payload copy；user page、ubuf_info、segment 和 error queue 形成额外生命周期。
6.1 的重点是 hot-path cache、page_pool recycle、multi-buffer XDP 和结构化丢包原因。
RK3588 BSP 必须区分通用 skb 语义、stmmac 实现和真实硬件能力，静态分析不能替代实机验证。

sk_buff 的难点从来不只是字段多，而是同一个对象不断改变数据视图、元数据状态和持有者。只要把“布局、字段、所有权、释放”四条线同时画出来，绝大多数网络栈源码都会从零散函数变成可推导的生命周期。

系列目录

Linux sk_buff 深度解析（一）：数据结构、四指针与核心字段
Linux sk_buff 深度解析（二）：非线性数据、引用计数与生命周期
Linux sk_buff 深度解析（三）：从网卡 DMA 到 Socket 的 RX 路径
Linux sk_buff 深度解析（四）：从 sendmsg 到 TX completion
Linux sk_buff 深度解析（五）：GRO、GSO、Checksum 与多核流调度
Linux sk_buff 深度解析（六）：Netfilter、tc、eBPF 与 XDP
Linux sk_buff 深度解析（七）：VLAN、隧道、分片与重组
Linux sk_buff 深度解析（八）：Socket 内存、零拷贝、丢包与版本演进（本文）

Linux sk_buff 深度解析（七）：VLAN、隧道、分片与重组

2026-07-14T23:00:00.000Z

写在前面

解释 VLAN metadata、inner/outer header、encapsulation、隧道 GSO/checksum，以及 IPv4/IPv6 分片队列和 frag_list 重组后的非线性布局。

阅读前先建立四个问题

阅读任何 skb 代码路径，都建议反复追问：

当前 skb->data 指向哪一层协议头，linear 与 non-linear 数据分别在哪里？
哪些字段刚被修改，下一层为什么依赖这些字段？
当前谁持有 skb shell、head、frag page 以及 socket/dst/conntrack 等外部引用？
成功、失败、重试、redirect 和丢弃分支分别由谁消费或释放 skb？

本篇核心结论

VLAN tag 可能在报文字节中，也可能只存在 skb metadata 中。
隧道 skb 同时保存 outer/inner header offset，offload 依赖这些元数据理解内层协议。
分片产生多个独立 skb，重组队列必须持有并在超时/错误时释放全部片段。
重组结果常用非线性布局或 frag_list，不能假设重新拼成一块连续内存。

结论摘要

skb 可用两种方式表达 VLAN：tag 仍在 packet bytes 中，或硬件已剥离并存入 vlan_tci/vlan_proto metadata。隧道通过 outer 与 inner header offset、encapsulation、inner protocol 和 GSO/checksum metadata 同时描述两套协议栈。封装需要 headroom/COW，解封装需要正确 pull/reset metadata；错误维护会影响路由、checksum、GSO 和 BPF/tc 解析。

一、VLAN 两种形态

包内 VLAN header

1	Ethernet dst/src → 802.1Q/802.1ad header → inner EtherType → payload

占用 packet bytes，data/len/header offset 反映真实 4 字节或多层 tag。

hardware-accelerated metadata

网卡 RX 可剥离 tag，把：

VLAN protocol；
TCI（VID/PCP/DEI）；
present bit

写入 skb 字段。packet bytes 中已没有该 tag，但协议栈仍能通过 helper 查询。

__vlan_hwaccel_put_tag() 写 metadata。TX 网卡若支持 VLAN insertion，可根据 metadata 在硬件发包时重新插入。

二、skb_vlan_untag

skb_vlan_untag() 在 kernel-5.10/net/core/skbuff.c:5499。它把 packet bytes 中的 VLAN header 解析/移除并转为 metadata，涉及：

确保 header 线性可读；
pull/memmove；
protocol 更新；
MAC header/len 调整；
COW/错误释放。

不能只减 len，否则 Ethernet 地址和 header offset 会错位。

三、VLAN push/pop

TC/BPF/bridge/VLAN device 可 push/pop tag：

push 需要 headroom 或 expand；
pop 需要确保 header linear；
修改 EtherType；
更新 MAC/network header；
处理 checksum/GSO；
metadata 与包内 tag 之间转换。

QinQ 可能有多层 tag，单个 vlan_tci 只表达当前 offload metadata 层，其余仍可能在 bytes 中。

四、隧道封装布局

以 VXLAN 为例：

outer Ethernet
outer IP
outer UDP
VXLAN
inner Ethernet
inner IP
inner TCP/UDP
payload

skb 需要同时保存：

outer MAC/network/transport header；
inner MAC/network/transport header；
outer protocol 与 inner protocol；
encapsulation=1；
GSO tunnel type；
outer/inner checksum 状态；
dst/tunnel metadata。

五、inner header helper

skb_reset/set_inner_mac_header()、network、transport helper 位于 kernel-5.10/include/linux/skbuff.h:2480-2553 附近。

典型封装前：

原 mac/network/transport → 保存为 inner_*
skb_push outer headers
重设 outer mac/network/transport
encapsulation = 1

由于 offset 相对 head，push data 不会自动破坏已保存 inner header 地址，但 expand head 后必须由 helper/复制逻辑保持 offset。

六、headroom 与 COW

封装向前添加几十字节 outer header，必须：

计算 LL_RESERVED_SPACE、隧道 header 等需求；
skb_cow_head() 确保 head 可写且空间足；
重新获取旧 header 指针；
push 并填写 outer header；
更新 len/protocol/checksum/GSO。

clone 的 skb 若直接写共享 head，会同时破坏其它路径。

七、VXLAN/Geneve/GRE 代表路径

VXLAN 实现在 kernel-5.10/drivers/net/vxlan/vxlan_core.c；
Geneve 在 kernel-5.10/drivers/net/geneve.c；
GRE 在 kernel-5.10/net/ipv4/ip_gre.c。

它们差异在 tunnel header、metadata/options 和 checksum，但 skb 层共同模式是：保存 inner header → COW/headroom → push outer → 设置 encapsulation/GSO → route/output。

八、隧道 GSO

一个大 inner TCP skb 可先封装再由网卡执行 tunnel TSO。gso_type 必须说明：

inner TCP/UDP 类型；
outer UDP tunnel/GRE；
outer checksum 是否需要；
partial GSO 等。

设备不支持时，软件可能在正确层次分段。错误的 inner header offset 会让分段器复制/修改错误 header。

九、解封装

RX 隧道 handler：

验证 outer header/checksum；
pull outer header；
恢复/重设 inner MAC/network/transport 为当前层；
更新 dev/protocol/hash/checksum；
清理或转换 tunnel metadata；
重新进入 GRO/RX stack。

outer checksum 已验证不自动等于 inner checksum 已验证；csum_level 表达层级。

十、字段变化表

操作	data/headroom	header offset	metadata
VLAN hw RX	bytes 中 tag 被剥离	L2 视图已调整	vlan_tci/proto present
VLAN push	data 向前/内容移动	MAC/network 调整	metadata 可能清除
tunnel encap	push outer headers	原 header 保存为 inner	encapsulation/GSO/dst
tunnel decap	pull outer	inner 提升为当前	dev/protocol/csum 更新

十一、常见误区

vlan_present 时 packet bytes 不一定含 VLAN header。
inner header 不是通过扫描自动得出，封装代码必须正确设置。
encapsulation 不只是一个 flag，还依赖 inner protocol/GSO/checksum。
push outer header 前必须 COW，不能只检查 headroom。
解封装后 hash/checksum/dev 可能需要重新评估。
隧道 GSO 支持取决于目标设备 feature，不是设置 gso_type 就一定可硬件执行。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
outer/inner header offsets	隧道封装/解封	同时定位两层协议头
`encapsulation/inner_protocol`	GSO/checksum	告诉 offload 如何解析内层
VLAN metadata	硬件剥离/插入	tag 可在 skb metadata 或报文数据中

最小调用链

原始 skb
→ VLAN metadata 或 push outer header
→ 设置 inner/outer offsets 与 encapsulation
→ GSO/checksum 处理
→ 解封装恢复内层视图

2. IP 分片、重组与 frag_list

结论摘要

IP 分片是网络协议语义，skb frags[] 是内存布局，两者不是同一概念。输出分片把一个 IP datagram 变为多个独立 skb，每个有自己的 IP header；接收重组把多个 fragment skb 排入 fragment queue，验证 offset/overlap/长度后生成一个重组 skb，可能通过 frag_list/非线性布局避免全量复制。

一、不要混淆两种 frag

skb frags[]:
  一个 skb 内部由多个 page 片段组成

IP fragments:
  多个独立 IP packet/skb，共同组成一个 datagram

一个 IP fragment skb 自己仍可拥有多个 frags[]；重组后的 skb 也可能非线性。

二、IPv4 输出分片入口

ip_fragment() 位于 kernel-5.10/net/ipv4/ip_output.c:582。触发条件通常是：

skb 长度超过输出 MTU；
DF 未禁止分片或本地策略允许；
GSO/设备 feature 不能在更后面解决；
PMTU/协议规则允许。

输出产生多个 skb，每个包含：

复制并调整的 IP header；
fragment offset/MF flag；
独立 total length/checksum；
datagram ID；
对应 payload slice。

三、fast path 与 slow path

若原 skb 已按合适 frag_list 组织、各子 skb headroom/长度满足要求，分片器可较少复制地重用/调整 skb 链。否则需要：

分配新 skb；
复制 header；
用 skb_copy_bits() 从原逻辑数据提取每片 payload；
维护 page ref、dst、metadata；
逐片调用 output。

分片后每个 skb 的 owner 独立，某一片输出失败时剩余链必须释放。

四、IPv4 接收重组

ip_defrag() 位于 kernel-5.10/net/ipv4/ip_fragment.c:475。fragment key 通常包括：

src/dst；
IP ID；
protocol；
user/zone 等上下文。

每片进入 queue：

校验 offset、MF、长度和边界；
按 offset 插入树/队列；
处理 overlap/duplicate；
更新已收到范围和总长度；
未完整则 queue 持有 skb；
完整后 ip_frag_reasm() 生成重组 skb。

queue timeout、内存阈值、overlap policy 或非法片都会释放相应 skb。

五、重组数据布局

重组不必把所有 payload memcpy 到一块大 linear buffer。常见结果：

第一片 skb 成为 head；
必要 header 保持 linear；
后续数据通过 frags/frag_list 连接；
调整 len/data_len/truesize；
清除 fragment flag、重算 header；
后续协议使用 pskb_may_pull() 获取所需连续 header。

这也是 frag_list 能表达“多个完整子 skb 组成一个逻辑包”的典型用途。

六、IPv6 差异

IPv6 路由器不进行中途分片，源主机通过 Fragment extension header 分片。接收重组实现位于 kernel-5.10/net/ipv6/reassembly.c。

差异包括：

fragment header 格式和位置；
atomic fragment 处理；
extension header 解析；
overlap 安全规则；
ICMPv6/PMTU 语义。

skb queue、所有权、重组非线性布局的基本问题仍相似。

七、Netfilter defrag

conntrack/NAT 需要完整 L4 header，因此 Netfilter 可在 PRE_ROUTING/LOCAL_OUT 早期 defrag。重组后的包完成 conntrack/NAT 后，输出可能根据 MTU 再次分片。

不同 ip_defrag user 值区分调用场景，避免错误复用 fragment queue 上下文。

八、GRO frag_list 与 IP frag_list

两者都可能使用 frag_list，但语义不同：

GRO：多个可聚合的同 flow packet 被当作大 skb 批处理，GSO metadata 保留 segment 边界；
IP reassembly：多个 IP fragments 组成原始 datagram，重组后对 L4 表现为一个 IP 包。

不能仅看到 frag_list 就判断来源。

九、所有权时间线

fragment skb arrives
→ defrag queue owns skb
  ├─ incomplete: retained until more fragments/timeout
  ├─ invalid/timeout: queue frees
  └─ complete: refs/data transferred into reassembled skb
→ L4 stack owns reassembled skb

输出方向原 skb 被分片器消费，产生的新 skb 链分别交 output；调用者需遵守 ip_fragment() 的消费合同。

十、资源与安全

fragment queue 容易被攻击消耗内存。内核使用：

高低阈值；
timeout；
LRU/eviction；
最大 datagram 长度；
overlap/duplicate 检查；
hash/secret；
per-netns accounting。

truesize 而非单纯 payload 长度更接近真实资源消耗。

十一、常见误区

skb_frag_t 与 IP fragment 不是一个层次。
重组完成不代表数据一定全 linear。
分片器可能消费原 skb，不能按普通只读函数理解。
IPv6 路由器不会像 IPv4 一样中途分片。
GRO 聚合与 IP 重组的 frag_list 语义不同。
fragment queue 必须计时和限内存，否则可被 DoS。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`frag_off/len`	IP 分片	每个片 skb 独立持有 data/page
fragment queue	defrag	队列在重组前持有所有片 skb
`frag_list/data_len`	重组结果	首 skb 持有后续片链并统一释放

最小调用链

大 IP skb output 分片或网络接收 fragments
→ fragment queue 持有各片
→ 完整性检查/重组
→ frag_list/nonlinear skb
→ 后续协议处理与统一释放

从局部机制回到完整路径

前面的局部机制只有放回完整生命周期才不容易误判：数据布局决定 helper 能否直接访问；引用计数决定能否原地修改；队列和驱动返回值决定谁仍然拥有 skb。遇到异常路径时，应按“外部引用 → 数据区 → shell”的逆序检查回收。

源码阅读路线

建议不要从 struct sk_buff 声明开始逐字段背诵，而应使用下面的阅读顺序：

先在入口函数确认 skb 是新分配、clone、队列取出还是从驱动 buffer 构造；
沿成功主线记录 data/len/data_len、header offset、checksum、hash、queue mapping 等字段变化；
再回到每个失败分支，确认 skb、page、DMA、socket 和记账引用是否回滚；
最后对照 5.10、6.1 或 BSP 的同名 symbol，区分语义变化、性能优化和 vendor backport。

本篇总结

VLAN tag 可能在报文字节中，也可能只存在 skb metadata 中。
隧道 skb 同时保存 outer/inner header offset，offload 依赖这些元数据理解内层协议。
分片产生多个独立 skb，重组队列必须持有并在超时/错误时释放全部片段。
重组结果常用非线性布局或 frag_list，不能假设重新拼成一块连续内存。

系列目录

Linux sk_buff 深度解析（一）：数据结构、四指针与核心字段
Linux sk_buff 深度解析（二）：非线性数据、引用计数与生命周期
Linux sk_buff 深度解析（三）：从网卡 DMA 到 Socket 的 RX 路径
Linux sk_buff 深度解析（四）：从 sendmsg 到 TX completion
Linux sk_buff 深度解析（五）：GRO、GSO、Checksum 与多核流调度
Linux sk_buff 深度解析（六）：Netfilter、tc、eBPF 与 XDP
Linux sk_buff 深度解析（七）：VLAN、隧道、分片与重组（本文）
Linux sk_buff 深度解析（八）：Socket 内存、零拷贝、丢包与版本演进

Linux sk_buff 深度解析（六）：Netfilter、tc、eBPF 与 XDP

2026-07-14T22:00:00.000Z

写在前面

从 Hook、verdict 和所有权出发，比较 Netfilter/Conntrack/NAT、tc action、eBPF __sk_buff 视图，以及 XDP 进入 skb 世界前后的边界。

阅读前先建立四个问题

阅读任何 skb 代码路径，都建议反复追问：

当前 skb->data 指向哪一层协议头，linear 与 non-linear 数据分别在哪里？
哪些字段刚被修改，下一层为什么依赖这些字段？
当前谁持有 skb shell、head、frag page 以及 socket/dst/conntrack 等外部引用？
成功、失败、重试、redirect 和丢弃分支分别由谁消费或释放 skb？

本篇核心结论

Hook 框架的核心不是“调用规则”，而是 verdict 如何改变控制流和 skb 所有权。
Conntrack、dst、socket、BPF metadata 都有独立于 skb shell 的引用语义。
struct __sk_buff 是 verifier 管理的 ABI 视图，不等于程序可任意解引用内核 struct sk_buff。
XDP 在 skb 分配前处理 RX buffer；只有 XDP_PASS 才通常进入完整 skb 生命周期。

1. Netfilter、Conntrack 与 NAT

结论摘要

Netfilter hook 把 skb 交给按优先级注册的 hook function。verdict 不只是允许/拒绝，还决定 skb 所有权：ACCEPT 继续，DROP 释放，STOLEN 表示 hook 已接管，QUEUE 把 skb 交给用户队列并等待 reinject，REPEAT 重跑当前 hook。conntrack 通过 skb _nfct 挂接共享连接引用；NAT 修改 header 前必须确保线性、可写并同步 checksum、route 状态。

一、hook 位置

IPv4 典型：

RX:
  PRE_ROUTING → route → LOCAL_IN 或 FORWARD → POST_ROUTING

TX local:
  LOCAL_OUT → route/output → POST_ROUTING

bridge、ARP、IPv6 有各自 hook family。skb 在不同 hook 时的 data/header/dev/dst 状态不同，hook 不能假定所有层都已解析。

二、nf_hook_slow

入口：kernel-5.10/net/netfilter/core.c:577。

它从 hook entries 指定索引开始遍历：

调用 hook function；
读取 verdict；
ACCEPT 继续下一个；
DROP 释放并返回错误；
QUEUE 调用 nf_queue()；
STOLEN 停止，skb 已被 hook 接管；
最终全部 ACCEPT 后调用 okfn 继续原协议路径。

三、verdict 与所有权

定义：kernel-5.10/include/uapi/linux/netfilter.h:11-15。

Verdict	skb 语义
`NF_ACCEPT`	Netfilter 不保留，继续下一 hook/okfn
`NF_DROP`	当前路径丢弃，core 负责或已执行释放
`NF_STOLEN`	hook 已接管 skb，调用者不能释放或继续
`NF_QUEUE`	queue subsystem 持有 skb，等待 verdict/reinject
`NF_REPEAT`	从当前 hook 再执行，需要避免无限循环

NF_DROP_ERR() 还能把 errno 编码进 verdict。

四、NFQUEUE 与 reinject

nf_queue() 位于 kernel-5.10/net/netfilter/nf_queue.c:246。queue entry 保存：

skb；
hook state；
当前 hook index；
设备/socket/netns 等引用。

用户空间给出 verdict 后 nf_reinject() 从保存位置继续。排队期间 skb 生命周期跨越异步用户交互，所以必须增加所有关联引用；queue overflow、进程退出或 verdict drop 都要释放。

五、conntrack

conntrack 识别 tuple、状态和方向，把连接对象引用编码在 skb->_nfct。skb clone/copy 时 __nf_copy() 增加引用，释放时 nf_conntrack_put()，见 skb_release_head_state()。

conntrack entry 是共享 flow 状态，不在 skb 数据区中。一个连接的多个 skb 指向同一对象；错误漏 ref 会 use-after-free，漏 put 会连接表泄漏。

六、NAT

nf_nat_packet() 位于 kernel-5.10/net/netfilter/nf_nat_core.c:695。NAT 根据 conntrack 方向修改：

IPv4/IPv6 地址；
TCP/UDP 端口；
ICMP 内嵌报文；
checksum；
可能触发 route 重新计算。

修改前必须保证：

相关 header 在线性区；
skb header 可写，必要时 skb_ensure_writable()/COW；
修改长度时 tailroom/headroom 合法；
checksum metadata 与实际字节一致；
cloned skb 不直接污染其它共享者。

七、skb 字段影响

_nfct：连接引用与 ctinfo；
mark：规则、策略路由和 tc 共享的通用标记；
nf_trace：trace 状态；
secmark：安全标记；
dev/sk/dst：hook state 与 route；
header offsets/checksum：NAT 修改；
extensions：可携带 secpath、bridge 等额外状态。

八、fragment 与 conntrack

L4 conntrack/NAT 需要端口，后续分片不一定含 L4 header。Netfilter defrag 在合适 hook 前重组，确保 conntrack 看到完整报文；之后转发/输出可能再次分片。

这意味着 skb 可能在 Netfilter 前后从多个 fragment skb 变成一个重组 skb，数据布局和 truesize 都会改变。

九、bridge Netfilter

桥接包可能同时经历 L2 bridge hook 与伪装成 L3 的 IPv4/IPv6 hook。nf_bridge/相关 extension 保存原设备、物理接口和 header 状态，避免二层/三层视图切换丢失信息。

不能只看 skb->dev 就判断原物理入口。

十、错误与释放

hook DROP：drop path 释放；
STOLEN：hook 自己最终释放或转交；
QUEUE：queue/reinject 负责；
NAT COW 失败：返回 drop/error 并释放；
conntrack invalid：按规则 accept/drop，引用仍需平衡；
clone 给日志/tap：每个引用独立释放。

十一、常见误区

NF_STOLEN 不等于 drop，它表示所有权被 hook 接管。
QUEUE 后原协议路径不能继续访问 skb。
conntrack 数据不在 packet bytes 中，而是 skb 外部引用。
NAT 不只是改地址，还要维护端口、checksum、route 和 clone 可写性。
mark 不是 conntrack state，但规则可互相读写。
hook 所在位置决定 header/data 是否可用，不能通用地直接 ip_hdr()。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`_nfct`	conntrack lookup/confirm	skb 持有 conntrack 引用
`mark`	规则、策略路由、tc	通用元数据跨 hook 传递
data/header/checksum	NAT/mangle	修改前确保可写并修正 checksum

最小调用链

协议栈进入 Netfilter hook
→ conntrack lookup/attach
→ rule verdict/mangle
→ NAT/confirm
→ ACCEPT 继续或 DROP/QUEUE 等路径消费 skb

2. tc ingress/egress 的分类与动作

结论摘要

tc ingress 位于 RX core 中，egress 位于 __dev_queue_xmit() 早期。classifier 读取 skb 字段/包数据生成 class result，action 可以修改、drop、redirect、mirror、reclassify 或继续。TC_ACT_STOLEN/REDIRECT/SHOT 都涉及消费语义，但具体由 action/core 合同决定。mirred mirror 通常 clone，redirect 通常把原 skb 改 dev 后转交。

一、入口位置

ingress：sch_handle_ingress()，kernel-5.10/net/core/dev.c:5000，RX core 调用点约 5241；
egress：sch_handle_egress()，kernel-5.10/net/core/dev.c:3904，__dev_queue_xmit() 调用点约 4134。

因此：

1 2	RX driver/GRO → ingress tc → rx handler/protocol stack TX IP output → egress tc → TX queue/qdisc → driver

redirect 后可能重新进入另一个设备的 RX/TX 路径，必须有递归/loop 防护。

二、classifier

tcf_classify() 位于 kernel-5.10/net/sched/cls_api.c:1583，内部 __tcf_classify() 在 1529。

classifier 可依据：

protocol/VLAN；
IP/port；
mark/priority/tc_index；
skb hash；
BPF 程序结果；
flower/u32 等 key。

结果可能选择 classid 或执行 action chain。classful qdisc 也可调用同一分类框架。

三、action 执行

tcf_action_exec() 位于 kernel-5.10/net/sched/act_api.c:675。action chain 按序执行，每个 action 返回控制码：

TC_ACT_OK：停止 action chain并正常继续；
TC_ACT_PIPE：继续下一个 action；
TC_ACT_RECLASSIFY：回到分类；
TC_ACT_SHOT：丢弃；
TC_ACT_STOLEN：action 接管 skb；
TC_ACT_REDIRECT：重定向并消费当前路径；
trap 等其它扩展语义。

常量见 kernel-5.10/include/uapi/linux/pkt_cls.h:60-67。

四、mirred

tcf_mirred_act() 位于 kernel-5.10/net/sched/act_mirred.c:228。

mirror

为了让原路径继续，同时给目标设备一个副本，通常 clone skb：

1 2	original skb → continue clone skb → target dev

clone 共享数据，修改前仍需 COW。

redirect

原 skb 改变 dev 后交给目标路径，当前路径停止：

1 2	original skb → target dev current path → consumed

需要处理 MAC header push/pull、ingress/egress 方向、redirected/from_ingress 标志和 nesting level。

五、skb 字段

mark：规则/action 通用标记；
priority：qdisc/class 优先级；
tc_index：tc index；
tc_skip_classify：避免重复分类；
tc_at_ingress：当前方向；
redirected/from_ingress：redirect 状态；
dev：目标设备；
queue_mapping：跨设备后可能重置；
cb：qdisc/tc 临时数据；
checksum/header offsets：改包 action 必须同步。

六、修改 packet data

pedit、BPF、VLAN push/pop、tunnel key 等 action 修改 skb 时必须考虑：

header 是否在线性区；
cloned head 是否可写；
headroom/tailroom；
checksum 更新；
GSO/encapsulation metadata；
旧 data pointer 失效；
redirect 目标设备 feature 差异。

修改 GSO skb 的 header 比普通包更敏感，因为一个逻辑修改会影响所有未来 segment。

七、ingress 与 egress 的 data 视图

ingress 时 MAC header 可能已 pull，但 skb_mac_header() 仍保存原 L2；某些 action 需要临时 push MAC header 再向 L2 设备 redirect。

egress 时 data 通常指向待发送 L2 header，但隧道/虚拟设备可能仍在构造过程中。action 应使用 header helper，而不是固定假设 data 指向 IP。

八、所有权表

Action/result	原路径	skb/clone owner
OK/PIPE	继续	tc 返回调用者
SHOT	停止	tc/core 释放
STOLEN	停止	action 接管
REDIRECT	停止	目标设备路径
MIRROR	原路径继续	clone 交目标，原 skb 返回
RECLASSIFY	重跑	tc 仍持有，需循环限制

九、与 qdisc 的关系

egress tc 通常在选择/进入 qdisc 前运行；
qdisc 内部也可绑定 classifier；
action 可改变 priority/classid/queue mapping；
redirect 可能完全绕开当前设备 qdisc，进入目标设备的新 TX/RX 流程；
qdisc cb 与其它 cb overlay 共享空间，必须遵守当前层所有权。

十、常见误区

tc 不只是 qdisc；ingress/egress classifier/action 可在排队外执行。
mirror 与 redirect 的关键区别是原路径是否继续及是否 clone。
STOLEN 后调用者不能再次释放 skb。
修改包后只改 bytes 不更新 checksum/GSO metadata 会产生坏包。
redirect 后原 queue mapping/设备 feature 不一定有效。
cb 是临时空间，不能把 tc 私有数据假定为跨协议层永久存在。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`tc_index/priority/mark`	classifier/action	影响分类、策略与后续队列
`redirected/dev`	mirred/redirect	动作改变设备和再次进入路径
data/header	pedit、vlan、tunnel action	修改前 COW，失败时 action 消费或丢弃

最小调用链

ingress/egress hook
→ classifier 读取 skb 元数据
→ action 修改/clone/redirect/drop
→ 重新进入设备或继续 qdisc/协议栈

3. eBPF 的 struct __sk_buff 受控视图

结论摘要

BPF 程序看到的 struct __sk_buff 是稳定的 UAPI 上下文，不是内核 struct sk_buff 的真实内存布局。verifier/JIT 把字段访问转换为底层 skb helper 或偏移访问。direct packet access 使用 data/data_end 边界；任何可能 pull、COW、扩展或重分配 head 的 helper 都会使已验证的数据指针失效，程序必须重新加载和检查。

一、两种结构不能混淆

UAPI 定义：kernel-5.10/include/uapi/linux/bpf.h:4088。

struct __sk_buff 暴露：

len、pkt_type、mark、queue_mapping、protocol、vlan；
priority、ingress_ifindex、ifindex；
tc_index、cb[5]；
hash、tc_classid；
data/data_end；
family、remote/local IP/port；
data_meta、flow_keys、tstamp、wire_len、gso_segs 等。

它的字段和大小属于 BPF ABI。内核 struct sk_buff 受配置、版本和 KABI 影响，不能直接暴露给程序。

二、上下文字段转换

不同 BPF program type 有自己的 convert_ctx_access：

tc classifier/action；
socket filter；
cgroup skb；
sk_skb/stream parser/verdict；
lwt 等。

verifier 根据字段、读写方向和 program type：

判断是否允许访问；
生成读取底层 skb 字段或调用 helper 的指令；
对写操作增加范围/语义检查；
某些字段返回派生值，而非一一映射。

因此相同 __sk_buff 字段在不同 program type 可能只读、可写或不可用。

三、direct packet access

程序常见模式：

void *data = (void *)(long)skb->data;
void *data_end = (void *)(long)skb->data_end;
if (data + sizeof(struct ethhdr) > data_end)
    return ...;

verifier 追踪 data 指针和边界证明。data_end 通常只覆盖当前可直接线性访问区域，不保证 frags 全部连续。

协议 header 访问前必须逐层边界检查，不能因为 skb->len 足够就直接解引用 linear data 之外的字节。

四、bpf_skb_pull_data

实现：kernel-5.10/net/core/filter.c:1830。

用途：

确保前 len 字节在线性区；
必要时调用 pull/linearize；
对 cloned skb 做 unclone，使后续 direct write 安全。

调用后所有旧的 packet pointers 都被 verifier 视为失效，必须重新读取 data/data_end 并重新边界检查。

五、修改 helper

bpf_skb_store_bytes

实现：kernel-5.10/net/core/filter.c:1684。在指定逻辑 offset 写数据，可选择重新计算/使 checksum 失效。需要处理 non-linear、clone 和边界。

bpf_skb_change_head / change_tail

改变 headroom 或 packet length，可能重新分配 head、移动 data、trim/expand。调用后 packet pointers 全失效。

bpf_skb_adjust_room

UAPI 文档约 kernel-5.10/include/uapi/linux/bpf.h:1712。可在 MAC/NET 等位置增减空间，用于封装/解封装；会更新或要求调用者更新：

header offsets；
checksum；
GSO/encapsulation metadata；
protocol 相关内容。

六、redirect 与 clone_redirect

bpf_redirect

程序记录目标 ifindex/map，返回 redirect action；实际执行阶段把原 skb 交给目标路径。当前路径不再继续。

bpf_clone_redirect

实现：kernel-5.10/net/core/filter.c:2430。先 clone skb，把 clone 发送到目标，原 skb 可继续在当前 BPF 程序/路径处理。代价包括新 shell、引用计数、目标发送路径。

clone 共享数据，因此目标路径或原路径修改 header 前仍需 COW。

七、checksum helper

BPF 修改地址、端口或 payload 后可使用：

bpf_l3_csum_replace()；
bpf_l4_csum_replace()；
bpf_csum_diff()；
store_bytes flags。

仅修改字节不维护 skb ip_summed、checksum 字段和 pseudo header，会使硬件 offload 或接收验证产生错误。

八、cb 的差异

struct __sk_buff.cb[5] 对 BPF 暴露 20 字节，不等于内核完整 skb->cb[48]。可用范围和跨 tail call/clone/层级的持久性受 program type 约束。

内核其它层仍会复用完整 cb，所以 BPF 元数据要跨 hook 传递时通常更适合 mark、priority、BPF metadata、maps 或明确的协议字段，而不是假定 cb 永久保存。

九、不同 program type 的 skb 语义

Program type	典型位置	主要动作
socket filter	socket 入队前	accept/truncate/drop
tc cls/act	ingress/egress	classify/edit/redirect
cgroup_skb	socket/cgroup 边界	policy/mark/drop
sk_skb	sockmap/skmsg 路径	parser/verdict/redirect
lwt	route/lightweight tunnel	encap/redirect

相同 helper 不一定在所有类型可用，verifier 根据 bpf_func_proto 限制。

十、所有权规则

BPF 程序本身通常借用 skb 上下文，不直接持有 C 引用。返回 action 决定由框架：

继续；
drop/free；
redirect/consume；
clone 后双路径；
socket queue。

程序不能保存 skb 指针到 map 跨调用使用。

十一、常见误区

__sk_buff 不是可用 BTF 直接解释的内核 skb 布局副本。
len 足够不代表 direct data 区连续足够。
pull/adjust/change helper 后旧 data 指针必须重新验证。
clone_redirect 与 redirect 的所有权和成本不同。
修改 header 后必须维护 checksum/GSO/header metadata。
BPF cb 只暴露内核 cb 的一部分，且有生命周期限制。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`__sk_buff` 字段	verifier 转译	程序看到受控上下文，不直接暴露全部内核结构
data/data_end	direct packet access	helper 或写操作后需重新验证指针
mark/priority/cb	BPF helper	修改效果和可用 helper 由 attach type 决定

最小调用链

attach point 生成 __sk_buff 上下文
→ verifier 将字段访问转换到真实 skb/helper
→ 程序读写 packet/metadata
→ verdict 决定继续、redirect 或 drop

4. XDP 与 sk_buff 的边界

结论摘要

native XDP 在驱动 RX buffer 上运行，发生在 skb 分配之前；generic XDP 在 RX core 中运行，操作已经存在的 skb。xdp_buff 是驱动/NAPI 周期中的可变 buffer 视图，xdp_frame 是可跨 redirect/TX 异步持有的固定 frame。XDP_PASS 后驱动才构造 skb；redirect/TX/drop 必须正确转移或归还 page_pool buffer。

一、native XDP 位置

NIC DMA → RX page/xdp_buff → BPF_PROG_RUN_XDP
  ├─ PASS → build_skb/napi_alloc_skb → GRO/stack
  ├─ DROP/ABORTED → recycle page
  ├─ TX → same device TX path
  └─ REDIRECT → xdp_frame/target → flush

它省去了被丢弃/重定向包的 skb shell 分配、初始化和协议栈成本。

二、generic XDP

do_xdp_generic() 位于 kernel-5.10/net/core/dev.c:4784，在 __netif_receive_skb_core() 中调用。此时：

skb 已分配；
packet 可能非线性；
helper 需要围绕 skb 构造 XDP 视图；
性能优势小于 native；
语义用于兼容没有驱动 native XDP 的设备。

不能用 generic XDP 的成功运行推断驱动支持 native XDP 或 XDP_TX 零拷贝。

三、xdp_buff

定义于 include/net/xdp.h，主要字段：

data；
data_end；
data_meta；
data_hard_start；
rxq；
frame size/flags（版本相关）。

它描述当前 RX buffer 的窗口，不负责像 skb 一样携带 socket、dst、Netfilter、qdisc 等丰富元数据。

BPF 可用 bpf_xdp_adjust_head/tail/meta 改变视图，但必须保持在驱动提供的 hard start/frame 范围内。

四、xdp_frame

redirect 或 XDP_TX 需要在当前驱动 poll 之外持有数据，不能长期持有栈上的 xdp_buff 描述。转换为 xdp_frame 后保存：

data 相对 frame 起始；
len；
headroom；
memory model；
frame size/metadata。

目标完成后通过 xdp_return_frame() 等根据 memory model 归还 page/page_pool。

五、XDP_PASS 到 skb

驱动常见策略：

XDP 程序可能调整 data/meta；
根据调整后的范围构造 skb；
build_skb() 包装原 page，或分配 skb 后 copy/attach frag；
设置 headroom、len、protocol、checksum、hash、queue；
交给 GRO。

若 build_skb 直接复用 page，skb free 必须知道如何返回内存池；若 copy，原 page 可立即 recycle。

六、redirect

xdp_do_redirect() 查找 devmap/cpumap/xskmap 等目标，把 frame/buffer 入目标批次。poll 尾部 xdp_do_flush() 才批量提交。

所有权时间线：

RX driver owns buffer
→ redirect accepted: redirect subsystem owns
→ target device/CPU/AF_XDP owns
→ completion/drop: memory model return callback

redirect 失败时当前路径必须回收，不能既交目标又 recycle。

七、XDP_TX

XDP_TX 通常把收到的 frame 从同设备发出：

交换/修改 MAC；
映射/复用 RX page；
放入专用 XDP TX ring；
completion 后归还 page_pool。

它不是普通 skb ndo_start_xmit，通常没有 qdisc/socket owner/truesize 语义。

八、multi-buffer XDP

Linux 5.10 的 XDP 主要假设单 buffer。Linux 6.1 提供：

xdp_buff_has_frags()：kernel-6.1/include/net/xdp.h:88；
xdp_update_skb_shared_info()：kernel-6.1/include/net/xdp.h:223。

多 buffer packet 在 XDP PASS 转 skb 时，需要把额外 page fragments 写入 skb_shared_info，同步：

nr_frags；
len/data_len；
truesize；
frag page ownership。

BPF 程序对 multi-buffer 数据访问能力也受版本/program support 限制。

九、RK3588 stmmac 边界

本地 Firefly BSP stmmac RX 笔记显示传统 skb/page_pool 构造路径。是否支持 native XDP 必须检查：

ndo_bpf/XDP setup；
RX poll 中 bpf_prog 执行；
xdp_rxq_info 注册；
XDP_TX ring；
redirect flush；
page_pool memory model。

如果这些闭环缺失，只能使用 generic XDP，不能因为内核启用 CONFIG_BPF 就声称 native 支持。

十、XDP 与 skb 功能边界

能力	XDP	skb stack
时机	驱动 RX 早期	构造 skb 后
元数据	精简 buffer/rxq/meta	socket/dst/nfct/qdisc/offload 等
排队	devmap/cpumap/xsk/XDP TX	backlog/socket/qdisc/TCP 等
典型目标	drop/redirect/fast TX	完整协议栈与 socket
内存	page_pool/driver model	slab head + page refs

十一、常见误区

XDP 不是“更快的 skb hook”，native XDP 根本还没有 skb。
generic XDP 已支付 skb 分配成本。
xdp_buff 不能异步长期持有，需转 frame。
redirect 成功后驱动不能再次 recycle page。
XDP_TX 不经过普通 qdisc/ndo_start_xmit 语义。
5.10 单 buffer 结论不能直接推广到 6.1 multi-buffer。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`xdp_buff` data pointers	驱动 RX/XDP	动作完成前仍是 RX buffer 所有权
`xdp_frame`	redirect/TX	转换后由目标设备或 map 完成路径持有
skb/shared_info	PASS/build_skb	跨入 skb 世界后遵守 skb/page_pool 回收语义

最小调用链

driver RX buffer/xdp_buff
→ BPF XDP verdict
→ PASS 构造 skb，TX/REDIRECT 转换 xdp_frame，DROP 直接回收
→ 对应 completion 释放

源码阅读路线

建议不要从 struct sk_buff 声明开始逐字段背诵，而应使用下面的阅读顺序：

先在入口函数确认 skb 是新分配、clone、队列取出还是从驱动 buffer 构造；
沿成功主线记录 data/len/data_len、header offset、checksum、hash、queue mapping 等字段变化；
再回到每个失败分支，确认 skb、page、DMA、socket 和记账引用是否回滚；
最后对照 5.10、6.1 或 BSP 的同名 symbol，区分语义变化、性能优化和 vendor backport。

本篇总结

Hook 框架的核心不是“调用规则”，而是 verdict 如何改变控制流和 skb 所有权。
Conntrack、dst、socket、BPF metadata 都有独立于 skb shell 的引用语义。
struct __sk_buff 是 verifier 管理的 ABI 视图，不等于程序可任意解引用内核 struct sk_buff。
XDP 在 skb 分配前处理 RX buffer；只有 XDP_PASS 才通常进入完整 skb 生命周期。

系列目录

Linux sk_buff 深度解析（一）：数据结构、四指针与核心字段
Linux sk_buff 深度解析（二）：非线性数据、引用计数与生命周期
Linux sk_buff 深度解析（三）：从网卡 DMA 到 Socket 的 RX 路径
Linux sk_buff 深度解析（四）：从 sendmsg 到 TX completion
Linux sk_buff 深度解析（五）：GRO、GSO、Checksum 与多核流调度
Linux sk_buff 深度解析（六）：Netfilter、tc、eBPF 与 XDP（本文）
Linux sk_buff 深度解析（七）：VLAN、隧道、分片与重组
Linux sk_buff 深度解析（八）：Socket 内存、零拷贝、丢包与版本演进

Linux sk_buff 深度解析（五）：GRO、GSO、Checksum 与多核流调度

2026-07-14T21:00:00.000Z

写在前面

把 GRO/GSO/TSO、checksum 四态以及 RSS/RPS/RFS/XPS 放在同一性能模型下，解释 skb 元数据如何替代重复解析和拷贝。

阅读前先建立四个问题

阅读任何 skb 代码路径，都建议反复追问：

当前 skb->data 指向哪一层协议头，linear 与 non-linear 数据分别在哪里？
哪些字段刚被修改，下一层为什么依赖这些字段？
当前谁持有 skb shell、head、frag page 以及 socket/dst/conntrack 等外部引用？
成功、失败、重试、redirect 和丢弃分支分别由谁消费或释放 skb？

本篇核心结论

GRO 在 RX 聚合，GSO/TSO 在 TX 延迟分段，二者通过 shared info 元数据衔接。
ip_summed 表达 checksum 的责任归属，而不是简单的“正确/错误”。
hash、CPU 和 queue mapping 把包内容映射为处理位置与发送队列。
offload 的本质是延后工作或把工作交给硬件，但软件始终要维护可验证的语义。

1. GRO、GSO 与 TSO 的对称关系

结论摘要

GRO 在 RX 方向把同流小包聚合成大 skb，减少后续协议栈每包开销；GSO 在 TX 方向用一个大 skb 描述多个线速报文，把分段推迟到软件出口或网卡；TSO 是 TCP GSO 的硬件执行形式。三者都依赖 skb 的非线性布局、header offset、checksum 状态和 skb_shared_info 中的 GSO 元数据。

一、收发方向的对称关系

1 2	RX: many wire packets → GRO → one large skb → protocol stack TX: one large skb → GSO/TSO → many wire packets

它们优化的不是字节复制本身，而是把固定 per-packet 成本摊薄：协议解析、路由、Netfilter、socket queue、qdisc、descriptor 等。

二、GRO 入口

Linux 5.10：

gro_list_prepare()：kernel-5.10/net/core/dev.c:5877；
dev_gro_receive()：kernel-5.10/net/core/dev.c:5991；
napi_gro_receive()：kernel-5.10/net/core/dev.c:6166。

驱动交入 skb 后，GRO 根据设备、协议、hash、header 和协议回调判断：

是否与已有 skb 同流；
当前包能否 merge；
旧 flow 是否必须 flush；
当前 skb 是 held、merged、normal 还是 drop。

三、napi_gro_cb

NAPI_GRO_CB(skb) overlay 在 skb->cb 上，保存：

same_flow；
flush；
free；
count；
age；
last；
checksum/GSO 相关临时状态。

GRO 期间 cb 属于 GRO；交给下一层后不能再假设这些字段有效。

四、GRO 合并后的数据形态

GRO 不只有一种布局：

把新数据页合入 head skb 的 frags[]；
使用 frag_list 串联完整 skb；
调整 len/data_len/truesize；
设置 GSO size/segs/type，让后续知道逻辑分段边界。

是否使用 frags 或 frag_list 取决于协议回调、输入 skb 布局、frag 数量、feature 和实现路径。不能把“GRO 后一定是 frag_list”当作通用结论。

五、flow 匹配与 flush

典型匹配条件包括：

同一接收设备/虚拟设备语义；
L2/L3/L4 header 与 flow key 一致；
TCP seq 连续、flag 合法；
checksum 状态兼容；
不超过 frag/GSO/长度限制；
没有要求立即 flush 的协议事件。

TCP FIN/RST、序列不连续、header option 差异、超限、时间/批次结束等会触发 flush。

六、GSO 元数据

位于 skb_shared_info：

gso_size：每个 segment 的 payload/MSS 规模；
gso_segs：预计 segment 数；
gso_type：TCPv4/TCPv6/UDP tunnel/partial/fraglist 等类型。

skb_is_gso() 通常依据 gso_size。大 skb 仍保持完整逻辑 len，网卡或软件分段器根据 header offset 和 GSO metadata 产生各 segment。

七、软件 GSO

关键路径：

validate_xmit_skb()
  → skb_gso_segment()/__skb_gso_segment()
  → protocol gso_segment callback
      → tcp_gso_segment()
      → skb_segment()

位置：

__skb_gso_segment()：kernel-5.10/net/core/dev.c:3391；
validate_xmit_skb()：kernel-5.10/net/core/dev.c:3659；
tcp_gso_segment()：kernel-5.10/net/ipv4/tcp_offload.c:54；
skb_segment()：kernel-5.10/net/core/skbuff.c:3819。

skb_segment() 尽量 clone/share page 数据并为每个 segment 构造独立 header，避免完整 payload copy。segment 链通过 skb next 返回。

八、TSO

如果设备 feature 支持对应 GSO type，网络栈可把大 skb 原样交给网卡：

descriptor 提供 MSS、header 长度、checksum 等；
网卡生成多个 wire packet；
驱动只管理一个逻辑 skb 的 DMA/completion。

若 feature 不支持，validate_xmit_skb() 先软件 GSO，再逐个 segment 发送。

九、checksum 关系

GSO skb 通常是 CHECKSUM_PARTIAL：header 中 checksum 字段留给软件分段器或网卡基于每个 segment 计算。GRO 输入 checksum 状态必须正确传播，否则聚合后一次错误标记会影响多个逻辑包。

十、5.10 与 6.1 GRO 组织差异

5.10 GRO 主实现位于 net/core/dev.c，NAPI 使用相对简单的 GRO list。6.1 把实现拆到 net/core/gro.c，并在 struct napi_struct 中使用：

1	struct gro_list gro_hash[GRO_HASH_BUCKETS];

GRO_HASH_BUCKETS 在 kernel-6.1/include/linux/netdevice.h:339 为 8。先按 hash 分桶减少同一 list 的线性比较，改善多 flow 批次成本。

十一、关键不变量

GSO type 必须与外层/内层协议和 feature 匹配。
header offset 必须能定位每个 segment 需要复制/修改的 header。
gso_size/gso_segs/len 必须一致或能由 helper 修正。
frag 数不能超过上限。
segment/merge 过程必须维护 page ref、truesize 和 checksum 状态。
GRO merge 消费当前 skb 后，调用者不能继续访问。

十二、常见误区

GRO 不是 LRO；GRO 是协议栈可控的软件聚合，保持更严格语义。
GSO 不等于硬件 TSO；不支持时可软件分段。
大 skb 不代表线上存在一个超 MTU Ethernet frame。
GRO 后不一定全部 linear，也不一定总是 frag_list。
gso_segs 可能需要重新计算，不能在所有路径视作绝对可信。
checksum offload 是 GSO 正确性的组成部分，不是独立附加功能。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
GRO cb/count	GRO receive/complete	聚合链持有成员或合并后的 skb
`gso_size/gso_segs/type`	协议 GSO	segment 前由大 skb 携带分段契约
frags/frag_list	聚合与分段	page/子 skb 引用随 segment 转移

最小调用链

小 skb 进入 GRO
→ flow 匹配并聚合
→ GRO complete 写 GSO 元数据
→ output/GSO segment
→ software 或 TSO 发送各 segment

2. Checksum 不是布尔值：四态责任模型

结论摘要

ip_summed 不是“checksum 是否正确”的布尔值，而是网络栈与驱动之间的责任状态机。RX 常见 NONE、UNNECESSARY、COMPLETE；TX 常见 PARTIAL。csum 与 csum_start/csum_offset 通过 union 复用，具体解释由 ip_summed 决定。GSO、隧道和多层 checksum 又通过 csum_level、inner header 和 gso type 扩展该模型。

一、四个状态

定义：kernel-5.10/include/linux/skbuff.h:221-225。

CHECKSUM_NONE

网络栈不能依赖硬件 checksum 结果。可能是：

驱动未验证；
协议不支持 offload；
硬件报告失败/未知；
状态被修改后失效。

L4 通常需要软件验证。

CHECKSUM_UNNECESSARY

驱动或上层已经确认协议 checksum 有效，协议栈无需再次计算。它不表示 skb->csum 保存了完整 checksum 数值，只表示验证责任已经完成。

CHECKSUM_COMPLETE

RX 硬件提供了从某范围计算的完整 checksum 值，保存在 skb->csum。协议层可结合 pseudo header 验证或在 pull/encapsulation 时增量调整。它与 UNNECESSARY 的区别是“有可继续使用的 checksum 数值”。

CHECKSUM_PARTIAL

TX 数据尚未完成 checksum，网卡或软件 helper 应从 csum_start 开始计算，并把结果写到 csum_start + csum_offset。

二、union 解释

struct sk_buff 中：

union {
    __wsum csum;
    struct {
        __u16 csum_start;
        __u16 csum_offset;
    };
};

RX COMPLETE 时解释为 csum；
TX PARTIAL 时解释为 start/offset；
不能同时把两种解释都当作有效。

csum_start 通常是相对 head 的 offset，不是相对当前 data 的稳定绝对地址。

三、RX 驱动责任

驱动只有在硬件明确验证相应协议和封装层时，才能设置 UNNECESSARY。常见限制：

硬件只验证 IPv4 header，不代表 TCP/UDP checksum；
分片、隧道、未知 extension header 可能使结果无效；
错误状态应保持 NONE；
skb_checksum_none_assert() 只是调试断言当前为 NONE，不会把包变成已验证。

csum_level 表示连续已验证的额外 checksum 层数减一，用于隧道内外层，但最大值有限。

四、TX PARTIAL

典型设置：

1
2
3

ip_summed = CHECKSUM_PARTIAL
csum_start = transport header offset
csum_offset = checksum field 在 transport header 内偏移

skb_partial_csum_set() 位于 kernel-5.10/net/core/skbuff.c:4857，会检查 start/offset 是否落在线性 head 范围内，设置 transport header 和 PARTIAL 状态。对不可信输入必须校验，否则网卡 DMA 可能向越界位置写 checksum。

五、软件 fallback

skb_checksum_help() 位于 kernel-5.10/net/core/dev.c:3230。当设备不支持当前 checksum offload 时：

确保 checksum 写入位置可写/线性；
软件计算 checksum；
写入协议 checksum 字段；
把状态转换为不再需要硬件处理。

skb_csum_hwoffload_help() 位于 kernel-5.10/net/core/dev.c:3648，结合设备 features 决定继续硬件 offload 或软件 fallback。

六、pull/push 与 checksum

改变 data 视图时，COMPLETE checksum 可能需要通过增量 helper 调整已经移除/加入的字节范围。直接修改 packet bytes 则会使原 checksum 状态失效，必须：

增量更新 checksum；
或降级为 NONE/重新计算；
PARTIAL 时更新 start/offset 和 header offset。

因此修改 header 的 NAT、tc/BPF、隧道代码通常同时调用 checksum helper。

七、GSO/TSO

GSO skb 通常保持 PARTIAL。每个 segment 的 TCP/UDP length、sequence、IP length 等不同，分段器或网卡基于 segment header 计算最终 checksum。

设备是否支持某个 GSO type，不自动意味着支持所有封装 checksum；feature negotiation 必须同时匹配 outer/inner checksum 能力。

八、隧道 checksum

隧道可能同时存在：

outer UDP/IP checksum；
inner TCP/UDP checksum。

skb 通过 outer/inner header offset、encapsulation、GSO type、csum_level 和 PARTIAL 字段表达当前最外层待 offload checksum。部分硬件支持两层 offload，部分只支持一层，网络栈需要 fallback。

九、字段变化表

场景	`ip_summed`	union	后续责任
普通 RX 未验证	NONE	不可信	L4 软件验证
RX 已验证	UNNECESSARY	通常不使用	L4 跳过重复验证
RX 完整和	COMPLETE	`csum`	协议结合 pseudo header
TX offload	PARTIAL	start/offset	网卡或软件 helper
软件 fallback 完成	NONE/已完成语义	checksum 字段已写	驱动无需 offload

十、常见误区

UNNECESSARY 不是 checksum 值为零。
COMPLETE 不是“已经完全验证”，它提供可验证的和。
PARTIAL 不是坏包，而是明确的 TX 工作合同。
修改 header 后不能保留旧 checksum 状态不管。
IPv4 header checksum 与 TCP/UDP checksum 是不同层。
GSO feature 和 checksum feature 必须组合检查。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`ip_summed`	RX 驱动、协议栈、TX	编码校验和责任状态
`csum`	COMPLETE 验证	随 pull/push 和协议处理调整
`csum_start/offset`	PARTIAL TX	设备或软件 helper 最终完成

最小状态调用链

RX descriptor/checksum metadata
→ driver 设置 ip_summed/csum/csum_level
→ GRO 与 L3/L4 验证或调整状态
→ 转发/本地发送重新决定 CHECKSUM_PARTIAL
→ GSO/软件 checksum helper 或网卡完成最终 checksum
→ skb 进入下一持有者或被释放

3. RSS、RPS、RFS 与 XPS 的多核流调度

结论摘要

skb->hash 是硬件 RSS 与软件 flow dissector、GRO、RPS/RFS、reuseport 等机制之间的公共 flow identity。RSS 在网卡接收前选硬件 RX queue；RPS 在 skb 已构造后选协议栈 CPU；RFS 在 RPS 基础上参考应用 socket CPU；XPS 在发送侧选 TX queue。它们解决的层次不同，不能互相等同。

一、hash 来源

硬件 RSS

网卡解析包头并计算 hash，按 indirection table 选择 RX queue。驱动读取 descriptor hash，通过 skb_set_hash() 写入：

skb->hash；
l4_hash 类型；
sw_hash=0。

软件 hash

若驱动没有提供，skb_get_hash() 检查 hash 是否为零，必要时调用 __skb_get_hash()，见：

kernel-5.10/include/linux/skbuff.h:1388-1393；
kernel-5.10/net/core/flow_dissector.c:1607。

flow dissector 从 L2/L3/L4 key 计算对称或规范 hash，并设置 sw_hash=1。

二、l4_hash 与 sw_hash

l4_hash=1：hash 基于规范四元组/传输端口，可用于更强的 flow 粒度；
l4_hash=0：可能只有 L3 或其它 hash；
sw_hash=1：软件计算；
sw_hash=0：通常来自硬件或外部设置。

hash 相同不保证包绝对属于同一流，仍可能碰撞；它是快速分桶索引，不替代完整 header 比较。

三、RSS

packet arrives
→ NIC computes hash
→ indirection table selects RX queue
→ queue IRQ/NAPI CPU
→ driver builds skb and records hash/queue

RSS 在 skb 产生之前完成，影响 DMA ring 和中断负载。它依赖硬件多队列。

四、RPS

get_rps_cpu() 位于 kernel-5.10/net/core/dev.c:4359。大致流程：

获取/计算 skb hash；
查看 RX queue 的 rps_map；
根据 hash 选择候选 CPU；
可结合 RFS flow table；
若目标 CPU 不同，enqueue_to_backlog() 排入目标 CPU。

enqueue_to_backlog() 位于 kernel-5.10/net/core/dev.c:4572。目标 CPU 的 softnet_data 使用 input_pkt_queue 接收远端 enqueue，再由 backlog NAPI 交换到 process_queue 批量处理。

RPS 发生在 skb 已分配之后，会增加跨 CPU enqueue、IPI/cacheline 成本，但可让单队列网卡利用多核协议栈。

五、RFS

RFS 目标是让 flow 在运行其应用线程的 CPU 上处理，提高 socket/cache locality。

核心结构：

rps_sock_flow_table：全局 hash → 应用最近 CPU；
rps_dev_flow_table：设备 RX queue flow 状态；
rps_dev_flow：记录 CPU 与 last_qtail，避免乱序迁移。

socket 收发路径通过 rps_record_sock_flow() 更新应用 CPU。get_rps_cpu() 比较 flow table，在安全队列边界后迁移 CPU，避免同一 TCP flow 因 CPU 切换产生重排。

六、XPS

XPS 是发送侧 queue steering：

socket/CPU sends skb
→ netdev_pick_tx()/get_xps_queue()
→ 根据 CPU/socket/flow map 选择 TX queue
→ skb->queue_mapping
→ qdisc/driver ring

目的包括：

让 CPU 固定使用局部 TX queue；
减少多个 CPU 对同一 queue lock/cacheline 竞争；
保持 flow 与 queue 稳定；
配合 IRQ/RSS 建立 RX/TX affinity。

七、queue_mapping

RX 时驱动可用 skb_record_rx_queue() 记录来源 queue；TX 时 queue_mapping 表示选择的发送 queue。字段复用但路径语义不同。

routing、tc redirect、设备层级变化后 queue mapping 可能需要重置或重新选择，不能把输入 queue 机械当作输出 queue。

八、四者对比

机制	执行位置	选择对象	是否需要 skb	主要目标
RSS	网卡硬件	RX queue	否	硬件分流/IRQ 多队列
RPS	RX core 软件	协议栈 CPU	是	软件多核处理
RFS	RPS + socket 反馈	应用所在 CPU	是	socket cache locality
XPS	TX queue selection	TX queue	是	发送队列局部性/降竞争

九、GRO 与 hash

GRO 使用 hash 快速寻找候选 flow，但仍由协议回调确认 header/sequence。硬件 hash 类型错误可能降低聚合效率或错误分桶；软件可在必要时重新计算。

6.1 GRO hash bucket 把同一 NAPI 的 flow 按 hash 分桶，进一步体现 skb->hash 的跨子系统价值。

十、性能与顺序约束

RSS/RPS map 应结合 NUMA、IRQ affinity、应用绑核；
RPS 过宽会增加 IPI 和 cache miss；
同 flow CPU 迁移必须考虑 backlog qtail，避免乱序；
XPS queue 选择需稳定，TCP 乱序/锁竞争都受影响；
hash collision 只影响候选分桶，协议逻辑仍应验证完整 flow。

十一、常见误区

RSS 与 RPS 都“分流”，但一个在硬件 skb 前，一个在软件 skb 后。
RFS 不是让应用线程直接执行 NAPI，而是让协议栈 CPU 靠近应用。
XPS 选 TX queue，不是选发送 CPU。
queue_mapping 不是永久属性，跨设备 redirect 后可能失效。
hash 不一定含端口，需看 l4_hash。
开启所有 RPS CPU 不一定更快，可能增加跨核成本。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`hash/l4_hash`	RSS 或 flow dissector	RPS/RFS/GRO/reuseport 读取
`queue_mapping`	XPS/queue select	TX qdisc 与驱动队列读取
CPU backlog/flow table	RPS/RFS	enqueue 后目标 CPU 持有 skb

最小调用链

驱动/RSS 或 flow dissector 产生 hash
→ RPS/RFS 选择 RX CPU/socket locality
→ TX XPS/queue selection
→ qdisc 与设备队列

源码阅读路线

建议不要从 struct sk_buff 声明开始逐字段背诵，而应使用下面的阅读顺序：

先在入口函数确认 skb 是新分配、clone、队列取出还是从驱动 buffer 构造；
沿成功主线记录 data/len/data_len、header offset、checksum、hash、queue mapping 等字段变化；
再回到每个失败分支，确认 skb、page、DMA、socket 和记账引用是否回滚；
最后对照 5.10、6.1 或 BSP 的同名 symbol，区分语义变化、性能优化和 vendor backport。

本篇总结

GRO 在 RX 聚合，GSO/TSO 在 TX 延迟分段，二者通过 shared info 元数据衔接。
ip_summed 表达 checksum 的责任归属，而不是简单的“正确/错误”。
hash、CPU 和 queue mapping 把包内容映射为处理位置与发送队列。
offload 的本质是延后工作或把工作交给硬件，但软件始终要维护可验证的语义。

系列目录

Linux sk_buff 深度解析（一）：数据结构、四指针与核心字段
Linux sk_buff 深度解析（二）：非线性数据、引用计数与生命周期
Linux sk_buff 深度解析（三）：从网卡 DMA 到 Socket 的 RX 路径
Linux sk_buff 深度解析（四）：从 sendmsg 到 TX completion
Linux sk_buff 深度解析（五）：GRO、GSO、Checksum 与多核流调度（本文）
Linux sk_buff 深度解析（六）：Netfilter、tc、eBPF 与 XDP
Linux sk_buff 深度解析（七）：VLAN、隧道、分片与重组
Linux sk_buff 深度解析（八）：Socket 内存、零拷贝、丢包与版本演进

Linux sk_buff 深度解析（四）：从 sendmsg 到 TX completion

2026-07-14T20:00:00.000Z

写在前面

打通 UDP/TCP sendmsg、IPv4 output、qdisc、ndo_start_xmit、stmmac DMA 映射与 TX clean，重点解释队列和驱动的 skb 所有权契约。

阅读前先建立四个问题

阅读任何 skb 代码路径，都建议反复追问：

当前 skb->data 指向哪一层协议头，linear 与 non-linear 数据分别在哪里？
哪些字段刚被修改，下一层为什么依赖这些字段？
当前谁持有 skb shell、head、frag page 以及 socket/dst/conntrack 等外部引用？
成功、失败、重试、redirect 和丢弃分支分别由谁消费或释放 skb？

本篇核心结论

协议层、qdisc、驱动和硬件 descriptor 依次成为 skb 的持有者。
dev_queue_xmit() 不等于立即发包，绝大多数 skb 会先经历 queue selection 与 qdisc。
NETDEV_TX_OK 表示驱动已经消费 skb；NETDEV_TX_BUSY 表示所有权仍归上层。
TX completion 负责 DMA unmap、descriptor 回收和最终 skb 消费，不能与 TCP ACK 生命周期混淆。

1. 从 sendmsg 到网卡完成的完整 TX 生命周期

结论摘要

发送方向由 socket/传输层创建并拥有 skb，经 IP 构造 header、Netfilter/routing、邻居与二层输出进入 dev_queue_xmit()。qdisc 排队后把 skb 交给驱动 ndo_start_xmit。驱动成功接收后拥有 skb，完成 DMA mapping 与 descriptor 发布；TX completion 才 unmap、完成 BQL 记账并 napi_consume_skb()。NETDEV_TX_BUSY 是关键例外：驱动不得消费 skb，调用者仍需保留/重试。

一、UDP 主链

sock_sendmsg()
  → inet_sendmsg()
  → udp_sendmsg()
  → ip_make_skb() 或 ip_append_data()
  → udp_send_skb()
  → ip_send_skb()
  → ip_local_out()
  → ip_output()
  → ip_finish_output()
  → neighbour output
  → dev_queue_xmit()

关键位置：

udp_sendmsg()：kernel-5.10/net/ipv4/udp.c:1040；
__ip_append_data()：kernel-5.10/net/ipv4/ip_output.c:967；
ip_append_data()：kernel-5.10/net/ipv4/ip_output.c:1314；
ip_make_skb()：kernel-5.10/net/ipv4/ip_output.c:1633；
ip_local_out()：kernel-5.10/net/ipv4/ip_output.c:120；
ip_output()：kernel-5.10/net/ipv4/ip_output.c:430。

二、UDP 构造 skb

UDP 需要决定：

connected/unconnected 目的地址；
route 与 MTU；
cork/MSG_MORE；
checksum；
GSO/UDP segmentation；
是否从用户 iterator 复制或 zerocopy。

ip_append_data() 可把数据追加到 socket write queue，形成一个或多个 skb；ip_make_skb() 使用临时 queue 一次构造并返回 skb。构造过程中预留 L2/L3/L4 headroom，payload 可在线性区或 frags 中。

socket 发送内存通过 skb_set_owner_w()、sk_wmem_alloc 与 sock_wfree() 记账。skb 进入不再需要 socket owner 的路径时可能 orphan，但 TCP 重传队列会长期保留 owner/计量。

三、TCP 与 UDP 的差异

TCP 不是每次 sendmsg 都立即生成并发送一个独立 datagram：

数据进入 TCP write queue；
TCP_SKB_CB 保存 seq/end_seq/flags；
skb 可能被合并、分段、clone；
原 skb/clone 可能留在 retransmit queue；
ACK 后才释放发送内存；
实际发送副本与重传状态必须分开管理引用。

因此 TCP skb 生命周期可能跨多个 RTT，远长于 UDP 单次输出。

四、IP output

IP 层完成：

设置 network header；
填写 IPv4 header、total length、ID、protocol、checksum；
附着 dst；
运行 LOCAL_OUT/POST_ROUTING Netfilter；
检查 MTU、分片或 GSO；
通过 neighbour/ARP 添加二层 header。

headroom 不足或 header 共享时，需要 COW/expand。任何扩展后旧 header 指针必须重新获取。

五、dev_queue_xmit 与 qdisc

入口：

__dev_queue_xmit()：kernel-5.10/net/core/dev.c:4108；
dev_queue_xmit()：kernel-5.10/net/core/dev.c:4219。

主要工作：

确定输出设备和 TX queue；
运行 egress tc；
处理 VLAN/offload feature；
选择 qdisc；
enqueue 或 noqueue 直接发送；
调度 dequeue；
dev_hard_start_xmit() 调用 ndo_start_xmit。

进入 qdisc 后 skb owner 是 qdisc；drop 时 qdisc 负责释放。dequeue 交给驱动后 owner 转移取决于驱动返回值。

六、驱动所有权合同

ndo_start_xmit() 典型返回：

NETDEV_TX_OK：驱动已经消费/接管 skb，调用者不能再访问；
NETDEV_TX_BUSY：驱动没有消费 skb，网络栈仍持有并重试。

驱动在返回 BUSY 前不能：

释放 skb；
部分不可逆地提交 descriptor；
丢失 DMA mapping 回滚信息。

现代驱动应尽量提前 stop queue，避免频繁 BUSY。

七、stmmac_xmit

入口：firefly_rk3588_SDK/kernel/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3468。

主要步骤：

选择 TX queue/ring；
检查可用 descriptor；不足则 stop queue/BUSY；
处理 GSO/TSO、VLAN、checksum offload；
DMA map skb linear head；
遍历 frags[]，逐片 DMA map；
填写 descriptor 长度、地址和 offload flags；
在软件 tx_skbuff[]/相关数组保存 skb 与 mapping；
设置 OWN，使用屏障保证 descriptor 内容先可见；
更新 cur_tx、BQL sent bytes；
通知 DMA tail pointer。

八、为什么 skb 常挂在最后一个 descriptor

一个 skb 可能占多个 descriptor。completion 按 descriptor 顺序清理；只有最后一个 descriptor 完成，才能确定整个 skb 的所有 DMA segment 都不再被硬件访问。

因此常见做法：

每个 descriptor 保存 DMA mapping 信息，便于逐个 unmap；
只在 packet 的最后一个 descriptor 保存 skb 指针；
clean 到最后一个时 consume skb。

若过早释放 skb，frag page 可能在 DMA 仍读取时被复用，造成数据损坏。

九、stmmac_tx_clean

入口：firefly_rk3588_SDK/kernel/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2087。

检查 descriptor OWN
→ 读取 TX status
→ dma_unmap_single/page
→ 到 packet last descriptor 时取回 skb
→ napi_consume_skb()
→ netdev_tx_completed_queue() / BQL
→ 推进 dirty_tx
→ 队列有空间时 wake

TX completion 是正常消费，语义上优先 napi_consume_skb()/consume_skb()，不是 drop 型 kfree_skb()。

十、错误与回滚

route/MTU/Netfilter 失败：IP/socket 层释放或返回错误；
qdisc enqueue drop：qdisc 释放；
driver ring 不足：BUSY，不消费；
DMA map 中途失败：驱动必须 unmap 已成功部分并释放/返回正确状态；
hardware TX error completion：仍需 unmap、记账并释放 skb；
timeout/reset：驱动 reset 路径必须清理所有 outstanding skb/mapping。

十一、所有权时间线

用户 buffer
  → socket/transport owns skb
  → IP/Netfilter/routing owns skb
  → qdisc owns skb
  → ndo_start_xmit:
       OK   → driver owns skb
       BUSY → qdisc/stack still owns skb
  → DMA owns packet bytes（driver 保存软件引用）
  → TX completion
  → driver unmap + consume skb

十二、常见误区

dev_queue_xmit() 返回后不能默认 skb 仍有效。
NETDEV_TX_OK 不等于包已经上线路，只表示驱动接管。
completion 才是普通异步驱动释放 skb 的安全点。
skb linear head 和 frags 需要不同 DMA mapping/unmap API。
TCP ACK 释放的通常是协议发送队列引用，与网卡 completion 的发送副本生命周期不能混淆。
BQL 统计字节完成不替代 skb 释放，两者必须同时正确。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`sk/truesize`	sendmsg 与协议队列	socket write memory 持有直到相应生命周期结束
`queue_mapping`	queue select/qdisc	qdisc 或设备队列持有 skb
DMA mapping/descriptor	stmmac xmit/clean	驱动提交后由 TX completion 归还

最小调用链

sendmsg()
→ UDP/TCP 构造和排队 skb
→ IP output
→ dev_queue_xmit/qdisc
→ stmmac_xmit/DMA
→ TX completion/clean/free

2. qdisc 排队、调度与驱动所有权

结论摘要

qdisc 位于协议栈和驱动之间，持有 skb 并实施分类、整形、调度、拥塞和丢包。__dev_queue_xmit() 选择 TX queue/qdisc，enqueue 成功后 qdisc 成为 owner；__qdisc_run() dequeue，sch_direct_xmit() 交给驱动。驱动返回 BUSY 时 skb 必须 requeue，返回 OK 时驱动接管。BQL 控制驱动队列在途字节，与 qdisc 队列形成上下游反馈。

一、主路径

__dev_queue_xmit()
  → egress tc
  → netdev_pick_tx()/queue_mapping
  → qdisc lookup
  → __dev_xmit_skb()
      ├─ enqueue
      └─ qdisc_run()
          → __qdisc_run()
          → dequeue_skb()
          → sch_direct_xmit()
          → dev_hard_start_xmit()
          → ndo_start_xmit()

关键位置：

__dev_queue_xmit()：kernel-5.10/net/core/dev.c:4108；
dev_hard_start_xmit()：kernel-5.10/net/core/dev.c:3611；
sch_direct_xmit()：kernel-5.10/net/sched/sch_generic.c:308；
__qdisc_run()：kernel-5.10/net/sched/sch_generic.c:404。

二、qdisc 的职责

FIFO/优先级/公平队列；
shaping/pacing；
classful 分类；
AQM，如丢包/ECN；
多队列设备的 queue qdisc；
统计 backlog、drops、overlimits。

skb 中参与决策的字段包括：

priority；
mark；
queue_mapping；
protocol；
hash；
tc_index；
qdisc cb 中的 packet length/classid 等。

三、enqueue 所有权

qdisc enqueue 的返回语义决定 skb 是否：

已入队；
被丢弃并释放；
被替换/重排；
需要调用者释放。

通用调用层根据 NET_XMIT_* 处理统计和返回。不能看到 enqueue 失败就无条件再 kfree_skb()，否则可能 double free。

入队后 qdisc 长期持有 skb，协议层不能再修改。qdisc dequeue 前可根据时间、token、flow、公平策略决定顺序。

四、运行与锁

qdisc_run() 使用运行状态位/锁确保同一 qdisc 不被并发重复执行。__qdisc_run() 在 quota 内循环 dequeue，避免一次占用 CPU 无上限。

dequeue 返回 skb 后，qdisc backlog accounting 相应减少；若后续驱动 BUSY，需要 requeue 并恢复相应状态。

五、sch_direct_xmit

sch_direct_xmit()：

从 qdisc 取出的 skb 交给 dev_hard_start_xmit()；
驱动 OK：skb 被驱动消费；
BUSY：skb 未消费，重新入队；
其它错误/部分 segment：按返回和剩余 skb 链处理；
更新 queue state 和统计。

源码在 kernel-5.10/net/sched/sch_generic.c:308-401，其中 351 附近明确说明 BUSY requeue。

六、noqueue

loopback、某些虚拟设备或明确 noqueue 设备可绕过普通 qdisc 排队直接调用驱动。noqueue 不代表无任何同步或不会 drop，只是没有标准软件排队层。

错误给需要排队的物理设备配置 noqueue，会把背压直接暴露到驱动 BUSY 路径。

七、queue stop/wake

驱动 ring 接近满时：

1 2	netif_tx_stop_queue() → qdisc 不继续向该 TX queue 下发

completion 释放足够 descriptor 后：

1 2	netif_tx_wake_queue() → qdisc 可重新运行

stop 必须在真正没有空间前与 producer 竞态正确同步，否则可能返回 BUSY 或 ring overflow。

八、BQL

Byte Queue Limits 按字节控制驱动硬件队列在途数据：

提交时 netdev_tx_sent_queue()；
completion 时 netdev_tx_completed_queue()；
动态调整允许的在途字节。

BQL 目标是减少网卡 ring 过深造成的 bufferbloat，同时保持设备不饿。它不替代 qdisc：

1 2	qdisc：选择哪些 skb 何时下发 BQL：限制驱动/硬件当前在途多少字节

九、watchdog 与 timeout

若 TX queue 长时间 stop 且没有 completion，watchdog 触发 ndo_tx_timeout。reset 路径必须清理：

outstanding descriptor；
DMA mappings；
保存的 skb；
BQL/accounting；
queue state。

否则会泄漏 skb/page 或重复 completion。

十、字段与所有权

阶段	owner	关键字段
`__dev_queue_xmit` 前	IP/stack	dev、dst、priority、mark
egress tc	tc/stack	mark、priority、redirect
qdisc enqueue 后	qdisc	queue_mapping、qdisc cb、hash
dequeue	qdisc/发送临界区	packet len、class/accounting
ndo OK	driver	DMA mappings、descriptor
ndo BUSY	qdisc	skb 必须 intact/requeue
completion	driver	unmap/BQL/consume

十一、常见误区

qdisc 不只是一条 FIFO；它可以分类、整形和 AQM。
驱动返回 OK 只表示接管，不表示已发送完成。
BUSY 时驱动不能释放 skb。
qdisc drop 的 skb 可能已被 enqueue API 消费，调用者需遵守返回合同。
BQL 不是 qdisc，也不是按 packet 数量限制。
queue mapping 选择错误会把流量送到错误 ring/qdisc，增加乱序和锁竞争。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`queue_mapping/priority`	TX select/tc	选择 netdev queue 与 class
qdisc node/cb	enqueue/dequeue	排队期间 qdisc 持有 skb
driver return code	`ndo_start_xmit`	OK 消费；BUSY 时所有权仍归上层

最小调用链

dev_queue_xmit()
→ 选择 netdev queue/qdisc
→ enqueue
→ schedule/dequeue
→ ndo_start_xmit()
→ OK 消费或 BUSY 退还所有权

从局部机制回到完整路径

源码阅读路线

建议不要从 struct sk_buff 声明开始逐字段背诵，而应使用下面的阅读顺序：

先在入口函数确认 skb 是新分配、clone、队列取出还是从驱动 buffer 构造；
沿成功主线记录 data/len/data_len、header offset、checksum、hash、queue mapping 等字段变化；
再回到每个失败分支，确认 skb、page、DMA、socket 和记账引用是否回滚；
最后对照 5.10、6.1 或 BSP 的同名 symbol，区分语义变化、性能优化和 vendor backport。

本篇总结

协议层、qdisc、驱动和硬件 descriptor 依次成为 skb 的持有者。
dev_queue_xmit() 不等于立即发包，绝大多数 skb 会先经历 queue selection 与 qdisc。
NETDEV_TX_OK 表示驱动已经消费 skb；NETDEV_TX_BUSY 表示所有权仍归上层。
TX completion 负责 DMA unmap、descriptor 回收和最终 skb 消费，不能与 TCP ACK 生命周期混淆。

系列目录

Linux sk_buff 深度解析（一）：数据结构、四指针与核心字段
Linux sk_buff 深度解析（二）：非线性数据、引用计数与生命周期
Linux sk_buff 深度解析（三）：从网卡 DMA 到 Socket 的 RX 路径
Linux sk_buff 深度解析（四）：从 sendmsg 到 TX completion（本文）
Linux sk_buff 深度解析（五）：GRO、GSO、Checksum 与多核流调度
Linux sk_buff 深度解析（六）：Netfilter、tc、eBPF 与 XDP
Linux sk_buff 深度解析（七）：VLAN、隧道、分片与重组
Linux sk_buff 深度解析（八）：Socket 内存、零拷贝、丢包与版本演进

Linux sk_buff 深度解析（三）：从网卡 DMA 到 Socket 的 RX 路径

2026-07-14T19:00:00.000Z

写在前面

以 RK3588 stmmac 为驱动实例，追踪 DMA page 构造 skb、NAPI/GRO/RPS、IPv4、TCP/UDP 到 Socket 接收队列的完整所有权变化。

阅读前先建立四个问题

阅读任何 skb 代码路径，都建议反复追问：

当前 skb->data 指向哪一层协议头，linear 与 non-linear 数据分别在哪里？
哪些字段刚被修改，下一层为什么依赖这些字段？
当前谁持有 skb shell、head、frag page 以及 socket/dst/conntrack 等外部引用？
成功、失败、重试、redirect 和丢弃分支分别由谁消费或释放 skb？

本篇核心结论

驱动不只交付字节，还要把长度、协议、checksum、hash、VLAN 等硬件结果编码进 skb。
NAPI/GRO/RPS 决定包何时批量处理、是否聚合以及在哪个 CPU 继续执行。
L3/L4 逐层消费 header 并把 skb 交给 socket receive/backlog queue。
每个返回码都隐含所有权契约：继续传递、排队、克隆、丢弃或已经消费。

1. RK3588 stmmac：从 DMA page 构造 skb

结论摘要

RK3588 BSP 的 stmmac RX 路径把 DMA descriptor 指向的 page 转换为一个 skb：首段通常复制到新分配 skb 的 linear head，后续段通过 skb_add_rx_frag() 零拷贝挂载。copy 路径中的 RX page 可立即返回 page_pool；frag 路径把 page 所有权转交给 skb，必须等 skb 释放。完整包补充 checksum、hash、RX queue、protocol 后交给 napi_gro_receive()。

一、调用位置

stmmac_napi_poll_rx()
  → stmmac_rx(priv, budget, channel)
      → 读取 RX descriptor
      → 处理首段/后续段
      → 完成 skb metadata
      → napi_gro_receive()
      → stmmac_rx_refill()

关键入口：

stmmac_rx()：firefly_rk3588_SDK/kernel/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3862；
stmmac_rx_refill()：firefly_rk3588_SDK/kernel/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:3740；
NAPI 调用点：firefly_rk3588_SDK/kernel/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:4081。

二、descriptor 与 buffer 所有权

RX descriptor 的 OWN 位区分 DMA 和 CPU 所有权：

OWN 属于 DMA：CPU 不能读取正在被硬件写入的 buffer；
OWN 被硬件清除：驱动可以读取状态和 packet data；
refill 完成并设置 OWN：buffer 再次交给 DMA。

驱动推进 cur_rx 只是软件消费进度，真正把 descriptor 重新交给硬件需要 refill、地址写入和内存屏障。

三、为什么首段复制到 linear head

典型逻辑：

1
2
3

napi_alloc_skb()
→ skb_copy_to_linear_data()
→ skb_put()

首段包含 Ethernet/IP/TCP 等协议头。将小的前部数据放入 linear 区有利于：

协议解析直接访问；
避免每层都调用 pskb_may_pull()；
改写 header 时更容易 COW；
RX page 复制后可立即返回 page_pool；
copybreak 在小包场景避免长期占用整个 page。

代价是一次 CPU copy，因此不是所有驱动和包长都采用完全相同策略。

四、后续段为什么挂 frags

多 descriptor 包的后续 page 通常不包含热协议头。驱动调用：

1	skb_add_rx_frag(skb, index, page, offset, size, truesize);

它把 page 描述加入 shared info，并更新 nr_frags/len/data_len/truesize。优点是避免复制大 payload，便于 GRO、协议栈和 TX scatter-gather 继续使用 page。

所有权变化：

1
2
3

挂 frag 前：RX ring/page_pool 管理 page
挂 frag 后：skb 持有该 page 引用
skb free：frag unref，5.10 BSP 由相应回收路径处理

驱动必须从 RX buffer bookkeeping 中移除或标记已转交的 page，再为 descriptor 分配/获取替代 page。

五、copy 与 frag 回收差异

路径	包数据去向	原 RX page	释放时机
首段 copy	skb linear head	数据已复制，可直接 recycle	当前 poll/refill 周期
后续 frag	skb `frags[]`	所有权转交 skb	skb 数据引用归零时

如果驱动把已经挂入 frag 的 page 又直接 recycle，会造成 use-after-free/DMA corruption；如果忘记转交后的回收路径，会泄漏 page。

六、半包状态

一个 frame 可能跨多个 descriptor，而 NAPI budget 或 ring 当前可用 descriptor 可能让处理暂时停止。驱动需要保存：

当前正在构造的 skb；
已消费长度；
下一个 descriptor；
是否已看到 last segment。

恢复后继续向同一个 skb 添加 frag。错误 descriptor、超长 frag 数、分配失败等路径必须释放已构造 skb，并正确处理尚未转交/已经转交的 page。

七、完成包的 metadata

checksum

若硬件确认 L3/L4 checksum 有效，驱动可设置 CHECKSUM_UNNECESSARY；否则保持 CHECKSUM_NONE。skb_checksum_none_assert() 只是断言当前状态，不等于硬件校验成功。

hash

硬件 RSS/hash 可通过 skb_set_hash() 写入 skb->hash 并设置 hash 类型。后续 GRO、RPS/RFS、reuseport 等可以复用，避免再次解析。

RX queue

skb_record_rx_queue() 把来源硬件队列记录到 queue_mapping，用于统计、socket RX queue 查询和流调度。

protocol

1	skb->protocol = eth_type_trans(skb, dev);

eth_type_trans() 不只是读取 EtherType，还保存/调整 MAC header、推进 data 到 L3 位置，并处理 packet type 等二层语义。因此不应在驱动中只手工赋一个常量替代。

八、交给 GRO

1	napi_gro_receive(&rx_q->napi, skb);

调用后 skb 所有权交给 GRO/网络栈。驱动不能继续访问或释放它。GRO 可能：

hold；
merge 并消费当前 skb；
flush 旧 skb；
normal receive。

返回值用于统计，不代表驱动重新获得 skb。

九、RX refill

stmmac_rx_refill() 为已经消费的 descriptor 准备新 buffer：

从 page_pool/分配器获取 page；
写入 descriptor buffer address；
清理软件状态；
使用正确屏障；
设置 OWN 交给 DMA；
更新 dirty/clean index。

refill 与构造 skb 是同一生命周期闭环：取 page → DMA 写入 → CPU 构造 skb/回收 → 补充新 page。

十、字段与所有权变化表

时点	linear/frags	`len/data_len`	page owner	skb owner
descriptor 完成	无 skb	-	RX ring/driver	-
首段 copy	linear 增长	len 增、data_len 0	原 page 可 recycle	driver
后续 frag	nr_frags 增	len/data_len 增	skb	driver
metadata 完成	header/hash/csum/queue 有效	不变	skb	driver
`napi_gro_receive`	可能被 GRO 重组	可能变化	network stack	GRO/stack

十一、BSP 适用边界

这是 Firefly RK3588 SDK 的 stmmac 具体实现，不应推广为所有网卡的唯一方式。其他驱动可能：

用 build_skb() 直接包装整页；
全部使用 frags；
使用 XDP 后再决定是否构造 skb；
使用不同 copybreak；
在更新版本中通过 pp_recycle 自动 page_pool 回收。

通用不变量仍然是：明确 descriptor、page 和 skb 三者所有权，metadata 完成后再把 skb 交给上层。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
RX page	page_pool/DMA	驱动与 page_pool 在 descriptor 和 skb 间转移
`len/data_len`	stmmac RX 构包	决定 linear 与 frag 数据边界
checksum/hash/VLAN	descriptor 状态解析	驱动写元数据，协议栈消费

最小调用链

stmmac RX descriptor 完成
→ page_pool/DMA 同步
→ build_skb/napi_build_skb
→ 填写长度和 offload 元数据
→ napi_gro_receive()

2. NAPI、GRO、RPS 与 RX core

结论摘要

驱动通过 napi_gro_receive() 交出 skb 后，GRO 决定 hold/merge/flush/normal。进入 __netif_receive_skb_core() 后，skb 依次经过时间戳/设备与输入接口初始化、generic XDP、VLAN、rx handler、ingress tc、Netfilter ingress、ptype tap 和协议 handler。每个 hook 都可能替换、clone、redirect、queue 或消费 skb，因此主路径使用 pt_prev 延迟投递以减少 clone，并严格维护所有权。

一、主调用链

napi_gro_receive()
  → dev_gro_receive()
  → napi_skb_finish()
      ├─ GRO_HELD / GRO_MERGED：当前 skb 被 GRO 持有或消费
      └─ GRO_NORMAL：gro_normal_one()/netif_receive_skb_internal()
          → __netif_receive_skb()
          → __netif_receive_skb_core()
          → packet_type handler
              → ip_rcv()/ipv6_rcv()/ARP/bridge/...

关键位置：

dev_gro_receive()：kernel-5.10/net/core/dev.c:5991；
napi_gro_receive()：kernel-5.10/net/core/dev.c:6166；
__netif_receive_skb_core()：kernel-5.10/net/core/dev.c:5168；
netif_receive_skb()：kernel-5.10/net/core/dev.c:5652。

二、GRO 交接语义

GRO result 不是简单成功/失败：

GRO_MERGED：当前 skb 数据已并入已有 skb，当前 skb 通常被消费；
GRO_MERGED_FREE：合并后还需特定释放；
GRO_HELD：skb 留在 NAPI GRO list；
GRO_NORMAL：不能合并，进入普通协议栈；
GRO_DROP：丢弃。

驱动调用后无论返回哪个结果，都不再拥有 skb。

三、进入 core 前的上下文

netif_receive_skb() 适用于进程/软中断等通用入口，内部可根据 RPS 决定本 CPU 直接处理或 enqueue 到目标 CPU backlog。__netif_receive_skb() 是更内部的直接版本。

RPS 可能让 skb 先进入另一个 CPU 的 softnet_data.input_pkt_queue，之后由 backlog NAPI 再调用 core。于是“驱动 poll CPU”不必等于“协议栈执行 CPU”。

四、__netif_receive_skb_core 的关键阶段

1. 初始化输入语义

函数保存 orig_dev，设置/维护 skb_iif，处理 pfmemalloc 和时间戳等状态。skb->dev 在 bridge、bond、VLAN、redirect 等路径中可能变化，所以原始设备和当前设备需要区分。

2. generic XDP

若设备挂载 generic XDP，do_xdp_generic() 在 kernel-5.10/net/core/dev.c:4784，调用点约 5201。此时 skb 已经存在，与 native XDP 的“构造 skb 之前”不同。

XDP verdict 可能 pass、drop、tx、redirect；非 pass 时 skb 可能已消费，core 不能继续使用原指针。

3. VLAN untag/metadata

skb_vlan_untag() 可把包内 VLAN header 转成 skb VLAN metadata，并调整 data/header。硬件已经剥离的 VLAN tag 则可能直接存在 vlan_tci/vlan_proto。

4. ptype_all tap

AF_PACKET/tcpdump 等 tap 通过 ptype_all 观察包。一个 skb 需要交给多个 handler 时不能让第一个 handler 独占原 skb，因此核心通过 clone 或 deliver_skb() 增加引用。

5. ingress tc

sch_handle_ingress() 位于 kernel-5.10/net/core/dev.c:5000，调用点约 5241。tc action 可修改、drop、redirect、mirror 或 consume skb。

6. Netfilter ingress

若配置 ingress hook，Netfilter verdict 决定继续、queue、stolen 或 drop。所有权取决于 verdict，不能按普通函数返回理解。

7. rx_handler

bridge、bond、macvlan 等设备可注册 rx_handler。它可能：

消费 skb；
修改 skb->dev 后重新开始；
精确传递；
让 skb 继续普通协议分发。

8. protocol handler

根据 skb->protocol 在 ptype_base 中找到 IPv4、IPv6、ARP 等 handler。IPv4 通常进入 ip_rcv()。

五、pt_prev 延迟投递

core 遍历多个 packet_type handler 时，用 pt_prev 暂存前一个 handler：

发现下一个匹配者时，才把 skb 引用交给前一个；
最后一个 handler 可直接获得原 skb；
减少不必要 clone/ref 操作。

这是一种热路径所有权优化。阅读代码时需同时追踪 skb 与 pt_prev，否则容易误判一个 handler 是否拿到原 skb。

阶段	典型变化
驱动完成	`dev/protocol/hash/ip_summed/queue_mapping` 已设置
GRO	`len/data_len/frags/frag_list/GRO cb` 可能变化
generic XDP	data/head/len/redirect 可能变化
VLAN	VLAN metadata、protocol、data/header 变化
rx_handler	`dev`、protocol 或所有权变化
ingress tc/NF	mark、priority、data、redirect、nfct 等变化
ptype/L3	network header、dst、cb overlay 变化

任何可能重分配 head 的 hook 之后，旧 header 指针都不能继续使用。

七、所有权退出点

GRO merge/drop；
XDP drop/redirect/tx；
tc shot/stolen/redirect；
Netfilter drop/queue/stolen；
rx_handler consumed；
protocol handler 接管；
无 handler 时 core 释放。

core 的返回码通常用于统计，调用者不能因为返回“成功”就认为 skb 仍有效。

八、常见误区

netif_receive_skb() 不保证在当前 CPU 立即执行协议栈，RPS 可排队。
generic XDP 不是 native XDP，它已经有 skb。
skb->dev 在 core 内可能变化，orig_dev 用于保留原输入设备。
ptype tap 可能让一个包有多个观察者，需要引用/clone。
hook 返回后原 skb 可能已被消费或替换。
napi_gro_receive() 返回并不把所有权还给驱动。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`dev/protocol`	驱动与 `eth_type_trans()`	RX core 接管后逐层转交
`hash/napi_id`	GRO/RPS	决定聚合与 CPU 调度
skb shell	NAPI/GRO/backlog	返回码和 enqueue 结果决定消费方

3. IPv4、TCP/UDP 与 Socket 接收队列

结论摘要

IPv4 RX 先验证并规范化 skb，再经 PRE_ROUTING、路由输入和 LOCAL_IN 到达 L4 handler。UDP 查找 socket 后把 skb 作为完整 datagram 排入 receive queue；TCP 把 skb 交给连接状态机，可能进入 backlog、out-of-order queue 或 receive queue。socket 通过 truesize 而非包长进行内存计量，owner/destructor 负责在 skb 最终释放时归还计数。

一、IPv4 主链

ip_rcv()
  → ip_rcv_core()
  → NF_INET_PRE_ROUTING
  → ip_rcv_finish()
  → route input
  → ip_local_deliver()
  → NF_INET_LOCAL_IN
  → ip_local_deliver_finish()
  → ip protocol handler
      ├─ udp_rcv()
      └─ tcp_v4_rcv()

关键位置：

ip_rcv_core()：kernel-5.10/net/ipv4/ip_input.c:442；
ip_rcv()：kernel-5.10/net/ipv4/ip_input.c:537；
ip_local_deliver()：kernel-5.10/net/ipv4/ip_input.c:240；
ip_local_deliver_finish()：kernel-5.10/net/ipv4/ip_input.c:226。

二、ip_rcv_core 对 skb 的规范化

典型工作：

确保 IPv4 基本头在线性区；
校验 version、IHL、total length；
trim 掉 L2 padding，使 skb->len 与 IP total length 一致；
校验 IPv4 header checksum；
设置/清理 IPv4 控制块 IPCB(skb)；
丢弃 malformed packet。

trim 可能改变 skb 长度和非线性布局。失败路径会释放 skb，后续不能继续访问。

三、路由与 dst

PRE_ROUTING 后通过 route input 决定：

本机接收；
转发；
multicast/broadcast；
unreachable/drop。

路由结果附着为 skb dst，后续通过 dst input/output 回调继续。clone 时 dst 需要增加引用，free 时 skb_dst_drop()。

本地流量进入 ip_local_deliver()；分片包可能先调用 ip_defrag()，重组完成后才进入 L4。

四、L4 分发

ip_local_deliver_finish() pull/定位 IP header 后，根据 iph->protocol 查找 net_protocol：

TCP → tcp_v4_rcv()；
UDP → udp_rcv()；
其它协议对应 handler；
raw socket 可能同时获得副本。

协议 handler 接管 skb 所有权。IP 层不应在 handler 返回后再次释放同一 skb，除非约定明确。

五、UDP 接收

udp_rcv()
  → __udp4_lib_rcv()
  → socket lookup
  → checksum/filter/policy
  → udp_queue_rcv_skb()
  → sock_queue_rcv_skb()
  → sk_receive_queue

UDP 保留 datagram 边界，一个 skb 通常对应一个用户可读取的数据报。排队前会处理：

UDP length；
checksum；
multicast/broadcast 多 socket 分发；
socket filter；
policy/xfrm；
rcvbuf 限额。

一个 multicast 包可能需要 clone 给多个 socket。

六、sock_queue_rcv_skb 与 owner

sock_queue_rcv_skb() 位于 kernel-5.10/net/core/sock.c:474。通用逻辑会检查接收内存和 filter，然后把 skb 入 sk_receive_queue。

skb_set_owner_r(skb, sk) 通常：

设置 skb->sk = sk；
设置 destructor 为 sock_rfree；
按 skb->truesize 增加 socket 接收内存计量。

最终 skb free 时 destructor 归还 rmem。不能只在 dequeue 时手工减包长，因为 clone、frag、truesize 和异步释放会让计量失真。

七、socket backlog

如果 socket 当前被用户上下文持锁，软中断不能直接执行完整协议处理，通常通过 sk_add_backlog() 把 skb 放入 sk_backlog。

backlog 仍属于该 socket；
socket 解锁时调用 sk_backlog_rcv；
TCP 对应 tcp_v4_do_rcv()；
backlog 同样受内存 limit；
入队失败必须释放并计数 drop。

sk_add_backlog() 定义位于 kernel-5.10/include/net/sock.h:1032。

八、TCP 接收

tcp_v4_rcv()
  → 校验 header/checksum
  → socket lookup
  → 未锁：tcp_v4_do_rcv()
  → 已锁：sk_add_backlog()

关键位置：

tcp_v4_rcv()：kernel-5.10/net/ipv4/tcp_ipv4.c:1936；
tcp_v4_do_rcv()：kernel-5.10/net/ipv4/tcp_ipv4.c:1670。

TCP 不一定把原 skb 直接放入用户 receive queue。状态机可能：

消费纯 ACK；
合并相邻数据；
把乱序段放入 out-of-order rbtree/queue；
把按序数据进入 receive queue；
clone/split skb；
因窗口、状态、checksum、RST 等释放。

TCP_SKB_CB 使用 cb 保存 seq/end_seq/flags/sacked/timestamp 等 TCP 私有状态。

九、用户读取与最终释放

UDP recvmsg 通常从 receive queue dequeue 一个 datagram，复制或映射数据后 consume skb。TCP recvmsg 按字节流消费，一个 skb 可能部分读取、被切分或继续留队。

最终 users 归零后：

socket destructor 归还 rmem；
dst/nfct/extensions 释放；
frags/frag_list/head 释放；
shell 释放。

十、字段/所有权变化

阶段	关键字段	owner
IP 入口	network header、IPCB、len trim	IP stack
route	dst、dev 语义	routing/IP
LOCAL_IN	nfct/mark 可能变化	Netfilter/IP
UDP/TCP lookup	`sk` 候选	protocol
backlog/receive queue	cb、owner、truesize accounting	socket
recv/free	data 指针/len 可能推进	user syscall/socket

十一、常见误区

socket lookup 成功不等于立即进入 receive queue，TCP 状态机和 socket lock 会改变路径。
UDP datagram 与 TCP byte stream 对 skb 队列语义不同。
socket 内存按 truesize 计量，不按 skb->len。
backlog 不是 netdev backlog；前者是 socket 锁竞争路径。
IP 分片重组发生在 L4 分发之前。
skb->sk 不是从驱动开始始终有效，通常在 socket ownership 阶段建立。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
network/transport header	IPv4 与 TCP/UDP	L3/L4 解析前保证可访问
`sk/destructor`	socket queue	入队后 socket/队列持有 skb
dst/nfct	路由和 Netfilter	引用随接收、转发或丢弃释放

最小调用链

ip_rcv()
→ Netfilter PRE_ROUTING
→ 路由/local delivery
→ tcp_v4_rcv()/udp_rcv()
→ socket receive/backlog queue
→ recvmsg()/free

源码阅读路线

建议不要从 struct sk_buff 声明开始逐字段背诵，而应使用下面的阅读顺序：

先在入口函数确认 skb 是新分配、clone、队列取出还是从驱动 buffer 构造；
沿成功主线记录 data/len/data_len、header offset、checksum、hash、queue mapping 等字段变化；
再回到每个失败分支，确认 skb、page、DMA、socket 和记账引用是否回滚；
最后对照 5.10、6.1 或 BSP 的同名 symbol，区分语义变化、性能优化和 vendor backport。

本篇总结

驱动不只交付字节，还要把长度、协议、checksum、hash、VLAN 等硬件结果编码进 skb。
NAPI/GRO/RPS 决定包何时批量处理、是否聚合以及在哪个 CPU 继续执行。
L3/L4 逐层消费 header 并把 skb 交给 socket receive/backlog queue。
每个返回码都隐含所有权契约：继续传递、排队、克隆、丢弃或已经消费。

系列目录

Linux sk_buff 深度解析（一）：数据结构、四指针与核心字段
Linux sk_buff 深度解析（二）：非线性数据、引用计数与生命周期
Linux sk_buff 深度解析（三）：从网卡 DMA 到 Socket 的 RX 路径（本文）
Linux sk_buff 深度解析（四）：从 sendmsg 到 TX completion
Linux sk_buff 深度解析（五）：GRO、GSO、Checksum 与多核流调度
Linux sk_buff 深度解析（六）：Netfilter、tc、eBPF 与 XDP
Linux sk_buff 深度解析（七）：VLAN、隧道、分片与重组
Linux sk_buff 深度解析（八）：Socket 内存、零拷贝、丢包与版本演进

Linux sk_buff 深度解析（二）：非线性数据、引用计数与生命周期

2026-07-14T18:00:00.000Z

写在前面

深入 linear、frags、frag_list、users、dataref、page ref，串联 sk_buff 的分配、clone、copy、COW 与分层释放。

阅读前先建立四个问题

阅读任何 skb 代码路径，都建议反复追问：

当前 skb->data 指向哪一层协议头，linear 与 non-linear 数据分别在哪里？
哪些字段刚被修改，下一层为什么依赖这些字段？
当前谁持有 skb shell、head、frag page 以及 socket/dst/conntrack 等外部引用？
成功、失败、重试、redirect 和丢弃分支分别由谁消费或释放 skb？

本篇核心结论

len 是逻辑总长度，data_len 是非线性长度，二者不能与 tail-data 混为一谈。
skb shell、head buffer、frag page 分别由 users、dataref、page ref 保护。
clone 复制控制对象但共享数据；copy 创建独立数据；修改共享 head 前必须 COW。
释放不是一次 kfree()，而是按外部引用、数据区和 shell 分层回收。

1. 非线性数据布局：linear、frags 与 frag_list

结论摘要

一个 skb 的逻辑数据可由 linear head、skb_shared_info.frags[] 和 frag_list 三部分构成。frags[] 描述 page 的片段，适合 scatter-gather、RX page、sendpage 和零拷贝；frag_list 链接完整子 skb，常见于重组、GRO fraglist 或大消息组织。len 统计全部逻辑数据，data_len 统计非线性部分，遍历与修改必须使用能够跨三种布局的 helper。

一、三种数据组织

struct sk_buff shell
        │
        ├── head buffer
        │     └── [data, tail): linear data
        │
        └── skb_shared_info
              ├── frags[0..nr_frags-1] → page + offset + size
              └── frag_list → skb → skb → ...

逻辑顺序通常是：linear 数据在前，随后是 frags，再随后是 frag_list 中的 skb 数据。

二、skb_frag_t

本地 5.10 中：

1	typedef struct bio_vec skb_frag_t;

见 kernel-5.10/include/linux/skbuff.h:324。bio_vec 本质描述：

page；
page 内 offset；
片段长度。

访问应使用：

skb_frag_page()；
skb_frag_off()；
skb_frag_size()；
对应 set/add/sub helper。

不要直接依赖 bio_vec 内部字段名，这些 helper 同时表达 skb 层的抽象边界。

三、MAX_SKB_FRAGS

kernel-5.10/include/linux/skbuff.h:305-317 说明设计目标：允许一个约 64 KiB frame 由 page fragments 表达，同时至少保留 16 个 frag 供 GRO 使用。

#if (65536/PAGE_SIZE + 1) < 16
#define MAX_SKB_FRAGS 16UL
#else
#define MAX_SKB_FRAGS (65536/PAGE_SIZE + 1)
#endif

nr_frags 必须不超过有效上限。驱动或 GSO 合并前需要检查 frag 数量，不能无限追加。

四、frags[] 的生命周期

skb_add_rx_frag() 声明于 kernel-5.10/include/linux/skbuff.h:2236-2237。它把 page/offset/size 写入指定 frag，并同步更新：

nr_frags；
skb->len；
skb->data_len；
skb->truesize。

重要点：把 page 放入 frag 后，skb 释放路径会对该 page 执行 frag unref。驱动必须明确是否已经把 page 所有权转交给 skb，不能在转交后又直接回收同一引用。

clone 时多个 skb 可能共享 frag page，需要增加 page ref；最后一个引用释放时 page 才真正回收。Linux 6.1 还可结合 pp_recycle 把 RX page 返回 page_pool。

五、frag_list

skb_shared_info.frag_list 是一个 struct sk_buff * 链表，而不是 page 数组。每个成员本身又可以有 linear/frags/frag_list。

适用场景：

IP 重组后用一个 head skb 组织后续分片 skb；
某些 GRO fraglist 路径；
大消息或已有 skb 链包装。

遍历使用：

1	skb_walk_frags(skb, iter)

释放时 skb_release_data() 调用 kfree_skb_list(shinfo->frag_list)，见 kernel-5.10/net/core/skbuff.c:621-622。clone frag_list 时需要对每个子 skb skb_get()。

六、长度关系

1
2
3

skb->len       = linear + frags + frag_list
skb->data_len  = frags + frag_list
skb_headlen()  = skb->len - skb->data_len

skb_is_nonlinear() 直接检查 data_len，见 kernel-5.10/include/linux/skbuff.h:2159-2167。

skb_pagelen() 主要统计 linear + page frags；若还存在 frag_list，完整逻辑遍历需要继续进入子 skb，不能把 pagelen 与总 len 混为一谈。

七、truesize

追加 frag 时调用者传入 truesize 增量。它反映 skb 对内存系统和 socket accounting 的成本，不一定等于 frag size：

一个小片段可能独占较大 page；
page_pool、page fragment 或复用策略会改变计量；
frag_list 子 skb 自身也有 truesize。

错误的 truesize 会造成 socket 内存限制失真：过小可能让 socket 持有过多真实内存，过大则过早触发限额。

八、skb_copy_bits

skb_copy_bits() 是跨布局读取的通用 helper。它按逻辑 offset 依次处理：

linear 区；
frags[] 中的 page 片段；
frag_list 子 skb，必要时递归。

因此协议、加密、分段等代码不应自行假设数据连续。只要需要跨越不确定边界，就应使用能够处理非线性布局的 helper。

同类 helper 包括 skb_store_bits()、checksum/copy iterator 等。

九、linearize

1	skb_linearize(skb)

若 skb 已是线性，直接返回 0；否则调用 __skb_linearize()，见 kernel-5.10/include/linux/skbuff.h:3368-3371。

linearize 的目标是把逻辑数据整理到连续 head buffer。它可能：

分配更大的 head；
从 pages/frag_list 复制数据；
释放或减少原 frag 引用；
改变 head/data/tail 的绝对地址；
失败并返回 -ENOMEM。

代价与包长有关，热路径应尽量避免无条件 linearize。协议只需要前 N 字节连续时，优先 pskb_may_pull(N)。

十、frags 与 frag_list 对比

维度	`frags[]`	`frag_list`
元素	page 片段	完整 skb
数量	`nr_frags`、有上限	skb 链表
引用	page ref	skb `users`
常见来源	RX page、sendpage、SG、zerocopy	重组、GRO fraglist、大消息
遍历	frag helper	`skb_walk_frags()`
释放	`__skb_frag_unref()`	`kfree_skb_list()`
每个元素可带元数据	否，只有 page/offset/size	是，每个子 skb 有完整 metadata

十一、数据布局不变量

nr_frags <= MAX_SKB_FRAGS。
每个 frag 的 page 引用在 skb 持有期间有效。
len >= data_len。
skb_headlen = len - data_len。
frag_list 成员不能形成非法循环。
修改 frag size/offset 时必须同步长度和 accounting。
需要写 page 数据前必须确认可写性和共享状态。

十二、常见误区

非线性不代表“数据不连续的顺序不确定”，逻辑字节顺序仍明确。
frags[] 不是 IP fragments；前者是内存布局，后者是网络层分片协议。
frag_list 不是普通 sk_buff_head，它是通过 skb next 串起来的子 skb 链。
data_len 不只统计 frags[]，也包含 frag_list 数据。
linearize 不是零成本，且可能让旧 header 指针失效。
page 放入 skb frag 后不能继续按驱动私有所有权随意释放。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`data_len/nr_frags`	追加 page frag	skb 持有 page 引用，free 时归还
`frag_list`	聚合/重组路径	父 skb 持有子 skb 链
`len/truesize`	追加、分段、重组	必须同步逻辑长度和内存计量

最小调用链

linear head
→ 添加 frags[] 或 frag_list
→ 更新 len/data_len/truesize
→ 协议处理或分段
→ 逐层释放 child skb/page ref/head

2. 分配、clone、copy、COW 与释放

结论摘要

skb 生命周期至少包含三类对象：skb shell、共享 head buffer/shared info、frag page/frag_list。users 保护 shell，dataref 保护共享 head，page ref 或子 skb users 保护非线性数据。clone 创建新 shell 并共享数据；copy 创建新 shell 和新 head 并复制数据；COW 在真正写入前把需要修改的 header/head 变为独占。释放路径按 head state、data、shell 分层进行。

一、分配路径

__alloc_skb

入口：kernel-5.10/net/core/skbuff.c:183-263。

主要步骤：

根据 SKB_ALLOC_FCLONE 选择 skbuff_fclone_cache 或 skbuff_head_cache；
从 slab 分配 skb shell；
对请求 size 做 cacheline 对齐，并增加 shared info 空间；
kmalloc_reserve() 分配 head buffer；
根据实际 ksize() 把 shared info 放到分配区尾部；
初始化 head=data=tail、end、truesize；
设置 users=1、dataref=1；
初始化 fclone 状态。

skb shell 与 head 分开分配，使 clone 可以只创建新 shell 而共享大块数据。

build_skb

build_skb() 位于 kernel-5.10/net/core/skbuff.c:331，用于把调用者提供的已有 buffer 包装成 skb。驱动可把 page fragment、RX buffer 或专用分配器得到的内存转为 skb，避免再次复制 payload。

调用者必须为尾部 shared info 留出空间，并明确 head buffer 的释放方式。head_frag 标志影响 skb_free_head() 使用 skb_free_frag() 还是 kfree()。

napi_alloc_skb

NAPI 场景使用 napi_alloc_skb()，本地 5.10 的实现会针对小 buffer/page fragment 和 NAPI 上下文优化分配。释放时 napi_consume_skb() 还能把 skb shell 延迟放入 per-CPU cache 路径，而不是立即 slab free。

二、三层引用关系

skb->users

保护 struct sk_buff shell。skb_get() 增加 users，kfree_skb()/consume_skb() 先通过 skb_unref() 减少引用，只有归零才进入真正释放。

skb_shared_info.dataref

保护共享 head/data 区。clone 增加 dataref。低 16 位表示完整数据引用，高 16 位表示 payload-only 引用，相关说明位于 kernel-5.10/include/linux/skbuff.h:543-550。

frag page / frag_list 引用

frags[]：page ref；
frag_list：每个子 skb 的 users；
zerocopy：ubuf_info 等额外引用。

这解释了为什么 users 归零并不代表可以直接 kfree head/page。

三、skb_clone

__skb_clone() 位于 kernel-5.10/net/core/skbuff.c:991-1021。

它创建或取得一个新 skb shell，然后：

清空新 shell 的 queue 链接；
不复制旧 sk；
复制协议/header/offload 元数据；
复制 len/data_len/tail/end/head/data/truesize；
新 shell users=1；
新 shell destructor 置 NULL；
dataref++；
原 skb 与新 skb 都标记 cloned。

结果：

1
2
3

skb A shell ─┐
             ├── shared head buffer + shared_info + frags
skb B shell ─┘

两个 shell 的 next/prev、部分 metadata 可以独立变化，但直接修改共享 head 中的字节前必须 COW。

fclone

fclone slab 一次预留 original 和一个常用 clone shell，减少典型 TX clone 场景再次从 slab 分配的成本。它优化 shell 分配，不改变 head 数据共享语义。

四、skb_copy

skb_copy() 位于 kernel-5.10/net/core/skbuff.c:1519。它分配新的 skb 和足够 headroom，然后复制整个逻辑数据，包括非线性内容，形成独立 linear 数据副本，再复制 header metadata。

结果：

1 2	skb A shell → head A skb B shell → head B

一般不共享 payload，代价是按包长度复制和更大内存开销。需要完全独立修改、设备不支持 SG、或必须线性数据时使用。

五、pskb_copy

__pskb_copy_fclone() 位于 kernel-5.10/net/core/skbuff.c:1558。partial copy 的核心是：

复制 linear head；
共享或增加引用保存 frags/frag_list；
新 skb 可以独立修改 linear header；
非线性 payload 仍然共享。

因此可概括为：

API	shell	linear head	frags/page
`skb_clone`	新	共享	共享
`pskb_copy`	新	复制	共享
`skb_copy`	新	复制	数据也复制/线性化为独立内容

具体实现还受 headroom、fclone、zerocopy、frag_list 等影响，不能只按名字判断所有细节。

六、headerless clone 与 nohdr

传输层可能只希望 clone payload，让下层为每个 clone 构造不同 header。nohdr 和 hdr_len 配合 dataref 高位区分 payload-only 引用。

基本目标：

payload 可共享；
原 skb 保留可修改 header 的能力；
clone 不应擅自修改共享 header。

这也是 skb_header_cloned() 与普通 skb_cloned() 分开的原因：数据区共享不必然意味着 header 当前不可写，要结合 full-data ref 与 payload-only ref 判断。

七、COW

clone 之后若要改 header：

1
2
3

检查 head 是否共享、headroom 是否足够
  ├─ 已独占且空间足：直接写
  └─ 共享或空间不足：pskb_expand_head() 创建新 head

skb_cow_head() 是常见入口。成功后调用者可写 header；失败通常是 -ENOMEM，必须停止修改并走错误释放路径。

COW 的性能价值是推迟复制：只读转发或观察路径不复制，只有真正写入时付出成本。

八、释放入口语义

kfree_skb

kernel-5.10/net/core/skbuff.c:705-713。它表示丢弃或错误释放语义，并触发 trace_kfree_skb。先减少 users，归零后 __kfree_skb()。

consume_skb

kernel-5.10/net/core/skbuff.c:844。表示正常消费完成，例如成功 TX completion。内存释放结果可能相同，但 trace/可观测语义不同。

napi_consume_skb

kernel-5.10/net/core/skbuff.c:908-930。在有效 NAPI budget 场景，普通 skb shell 可进入延迟/per-CPU 回收；fclone 等特殊情况直接完整释放。budget 为 0 时回退通用上下文路径。

九、分层释放

kfree_skb()/consume_skb()
  → skb_unref(users)
  → __kfree_skb()
      → skb_release_all()
          → skb_release_head_state()
          → skb_release_data()
      → kfree_skbmem()

skb_release_head_state

kernel-5.10/net/core/skbuff.c:661-672：

skb_dst_drop()；
调用 destructor；
nf_conntrack_put()；
skb_ext_put()。

这是 skb shell 附带的外部状态。

skb_release_data

kernel-5.10/net/core/skbuff.c:608-626：

若 cloned，减少 dataref；仍有人共享则立即返回；
unref 每个 frag page；
释放 frag_list 子 skb；
清理 zerocopy；
根据 head_frag 释放 head。

kfree_skbmem

根据 fclone 状态释放普通 shell 或整个 fclone 对象。

十、所有权转移原则

阅读任何返回 struct sk_buff * 或接受 skb 的 API 时，都要问：

成功后调用者是否仍持有 skb？
失败时函数是否已经消费 skb？
clone 是增加 shell 引用还是创建新 shell？
数据引用是否独立增加？
destructor、dst、nfct、zerocopy 是否被转移或复制？

网络栈常见 bug 不是算法错误，而是 double free、漏 ref、错误 orphan 或 busy 返回后错误消费 skb。

十一、常见误区

clone 不是浅拷贝一个 C 结构体；它有明确的引用和字段复制规则。
cloned=1 是快速提示，最终共享状态还看 dataref。
skb_copy() 与 pskb_copy() 不同，后者仍可共享非线性 payload。
kfree_skb() 不等于 kfree()。
destructor 主要处理 head state/owner，不直接替代 frag/head 的通用释放。
consume_skb() 与 kfree_skb() 的差异对 drop 可观测性很重要。
users、dataref、page ref、socket ref、dst ref 是不同层次，不能用一个“skb 引用计数”笼统概括。

5.10 到 6.1 的预告

Linux 6.1 在这些路径上的重要演进包括：

napi_skb_cache_get/put() 与 bulk slab 操作；
pp_recycle 让 frag/head page 在 skb free 路径回到 page_pool；
kfree_skb_reason() 改进丢包语义；
XDP multi-buffer 与 shared info 更新。

详细差异放在阶段 21。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`users`	skb_get/consume	保护 skb shell
`dataref`	clone/COW/free	保护共享 head 和 shared info
frag page ref	clone/copy/free	保护 page frag；深拷贝与共享路径不同

最小调用链

__alloc_skb()/build_skb()
→ skb_clone() 共享数据
→ skb_copy()/COW 获得私有数据
→ consume/kfree
→ users/dataref/page ref 分层归零

从局部机制回到完整路径

源码阅读路线

建议不要从 struct sk_buff 声明开始逐字段背诵，而应使用下面的阅读顺序：

先在入口函数确认 skb 是新分配、clone、队列取出还是从驱动 buffer 构造；
沿成功主线记录 data/len/data_len、header offset、checksum、hash、queue mapping 等字段变化；
再回到每个失败分支，确认 skb、page、DMA、socket 和记账引用是否回滚；
最后对照 5.10、6.1 或 BSP 的同名 symbol，区分语义变化、性能优化和 vendor backport。

本篇总结

len 是逻辑总长度，data_len 是非线性长度，二者不能与 tail-data 混为一谈。
skb shell、head buffer、frag page 分别由 users、dataref、page ref 保护。
clone 复制控制对象但共享数据；copy 创建独立数据；修改共享 head 前必须 COW。
释放不是一次 kfree()，而是按外部引用、数据区和 shell 分层回收。

系列目录

Linux sk_buff 深度解析（一）：数据结构、四指针与核心字段
Linux sk_buff 深度解析（二）：非线性数据、引用计数与生命周期（本文）
Linux sk_buff 深度解析（三）：从网卡 DMA 到 Socket 的 RX 路径
Linux sk_buff 深度解析（四）：从 sendmsg 到 TX completion
Linux sk_buff 深度解析（五）：GRO、GSO、Checksum 与多核流调度
Linux sk_buff 深度解析（六）：Netfilter、tc、eBPF 与 XDP
Linux sk_buff 深度解析（七）：VLAN、隧道、分片与重组
Linux sk_buff 深度解析（八）：Socket 内存、零拷贝、丢包与版本演进

Linux sk_buff 深度解析（一）：数据结构、四指针与核心字段

2026-07-14T17:00:00.000Z

写在前面

从 sk_buff 为什么不是一个简单 buffer 出发，系统解释 skb shell、linear head、shared info、四指针、header offset、核心字段与数据区操作。

阅读前先建立四个问题

阅读任何 skb 代码路径，都建议反复追问：

当前 skb->data 指向哪一层协议头，linear 与 non-linear 数据分别在哪里？
哪些字段刚被修改，下一层为什么依赖这些字段？
当前谁持有 skb shell、head、frag page 以及 socket/dst/conntrack 等外部引用？
成功、失败、重试、redirect 和丢弃分支分别由谁消费或释放 skb？

本篇核心结论

skb 是控制对象，包数据可能分散在 linear head、page frags 和子 skb 中。
head <= data <= tail <= end 描述 linear head，不等于整个逻辑包。
协议头使用相对 head 的 offset，因而能够承受 push/pull 和 head 重分配。
读字段时要同时问：谁写入、谁读取、当前谁持有 skb。

1. 为什么 Linux 网络栈需要 sk_buff

问题

Linux 网络栈为什么不只传递一个普通 buffer 指针？
head/data/tail/end 分别表示什么？
headroom、linear data、tailroom 和 skb_shared_info 如何布局？
skb 本体、head buffer、page frag 为什么有不同生命周期？
一个新 skb 从分配、构造到释放的基本过程是什么？

结论摘要

struct sk_buff 不是“网络包数据本身”，而是网络包的控制对象和元数据容器。真正的线性数据通常位于独立的 head buffer 中，非线性 payload 还可能位于 page fragments 或其它 skb 组成的 frag_list 中。

贯穿本阶段的长度恒等式是：skb->len = skb_headlen(skb) + skb->data_len。

四指针模型描述 head buffer 的线性部分：

1	head <= data <= tail <= end

head：已分配 head buffer 的起始地址；
data：当前协议层看到的线性数据起点；
tail：当前线性数据末尾；
end：线性可用区末尾，也是 skb_shared_info 的起始位置；
[head, data)：headroom；
[data, tail)：当前线性数据；
[tail, end)：tailroom，仅在线性 skb 语义下可直接追加。

需要特别注意：在 64 位内核中，本地源码定义了 NET_SKBUFF_DATA_USES_OFFSET，所以 tail 和 end 在结构体里实际是相对 head 的无符号 offset，而不是 C 指针。所谓“四指针模型”是概念模型；访问实际地址应使用 skb_tail_pointer()、skb_end_pointer() 等 helper。

一、为什么不能只使用普通 buffer 指针

网络包经过驱动、二层、三层、四层、Netfilter、qdisc、socket 等多个子系统。仅传递 void *data 无法同时解决以下问题。

1. 协议头需要频繁增加和移除

收包时，协议栈会逐层解析并“移过”当前视图；发包时，会从 payload 开始逐层向前添加 TCP/UDP、IP 和 Ethernet header。

使用 data 指针和预留 headroom 后，可以通过移动指针表达当前协议层，不必每经过一层就复制整个包。

2. 网络包需要排队和调度

skb 自带 next/prev，可以进入 socket queue、backlog、qdisc、TCP 重传队列等。包数据不需要为了排队而改变布局。

3. 网络栈需要携带大量元数据

例如：

输入/输出设备；
socket 所有者；
路由 dst；
MAC、network、transport header offset；
checksum offload 状态；
hash、RX/TX queue；
VLAN、GSO、timestamp、mark、priority；
destructor 和引用计数。

这些内容不是线速报文的一部分，不能直接塞入报文字节流。

4. 数据可能不是一段连续内存

高性能收发包会使用 page fragment、scatter-gather、GRO/GSO、零拷贝。skb 允许“一个逻辑网络包”由 linear data、frags[] 和 frag_list 共同组成。

5. 元数据与数据需要独立共享

clone 可以创建新的 skb shell，同时共享 head buffer 或 page 数据。这样不同路径可以拥有独立的队列节点和协议元数据，而不复制完整 payload。

因此可以把 skb 理解为：

1	sk_buff = 包的控制块 + 数据布局描述 + 协议元数据 + 生命周期管理

二、三个不同的对象

初学时最重要的是不要把下面三个对象混在一起。

对象 1：struct sk_buff
  - 从 skbuff_head_cache / skbuff_fclone_cache 分配
  - 保存元数据、队列节点、四指针/offset、len、users 等

对象 2：linear head buffer
  - 通常通过 kmalloc_reserve() 分配
  - 包含 headroom、linear data、tailroom
  - 尾部紧跟 struct skb_shared_info

对象 3：非线性数据 page / frag_list skb
  - 由 skb_shared_info.frags[] 或 frag_list 描述
  - 有独立的 page ref 或 skb ref

它们不是一次分配，也不是靠同一个引用计数保护。

三、linear head buffer 的内存布局

典型布局如下：

低地址                                                               高地址

head          data                     tail              end
 │             │                         │                 │
 ▼             ▼                         ▼                 ▼
 +-------------+-------------------------+-----------------+------------------+
 |  headroom   |      linear data        |    tailroom     | skb_shared_info  |
 +-------------+-------------------------+-----------------+------------------+
               <------- skb_headlen ------>

 skb_shared_info:
   nr_frags
   gso_size / gso_segs / gso_type
   frag_list
   dataref
   destructor_arg
   frags[MAX_SKB_FRAGS]

skb_shinfo(skb) 的定义直接把 skb_end_pointer(skb) 转换为 struct skb_shared_info *：

1 2	#define skb_shinfo(SKB) \ ((struct skb_shared_info *)(skb_end_pointer(SKB)))

位置见 kernel-5.10/include/linux/skbuff.h:1464。

因此：

end 不是整块 kmalloc 内存的真正末尾；
end 是 linear 可用区的末尾；
从 end 开始存放 skb_shared_info；
分配 head buffer 时必须额外给 shared info 留空间。

四、四指针分别代表什么

1. `head`

head 是 head buffer 的基址。正常的 push/pull/put/reserve 不改变它，只有重新分配 head 的操作才可能改变它。

2. `data`

data 是当前线性数据起点，也是协议栈当前视图的起点。

skb_push()：data 向低地址移动，通常用于添加协议头；
skb_pull()：data 向高地址移动，通常用于移除或越过协议头。

data 不一定始终指向 Ethernet header、IP header 或 payload；它的含义取决于当前执行阶段。

3. `tail`

tail 表示 linear data 的结束位置，也就是下一个可追加字节的位置。skb_put() 会向后推进 tail 并增加 len。

对于非线性 skb，tail 仍只描述 linear 区结束位置，不描述 page fragment 的末尾。

4. `end`

end 表示 linear 可用区的末尾，skb_shared_info 从这里开始。

在 64 位配置下：

1 2	skb_end_pointer(skb) = skb->head + skb->end; skb_tail_pointer(skb) = skb->head + skb->tail;

对应：

kernel-5.10/include/linux/skbuff.h:606-614
kernel-5.10/include/linux/skbuff.h:1432-1439
kernel-5.10/include/linux/skbuff.h:2244-2258

五、必须记住的长度关系

1. headroom

1	headroom = data - head

实现位于 kernel-5.10/include/linux/skbuff.h:2401-2404。

2. linear data 长度

1	skb_headlen(skb) = skb->len - skb->data_len

实现位于 kernel-5.10/include/linux/skbuff.h:2164-2167。

3. 总长度

1 2	skb->len = linear data length + non-linear data length = skb_headlen(skb) + skb->data_len

data_len == 0 表示 skb 是纯线性的；skb_is_nonlinear() 直接检查 data_len，见 kernel-5.10/include/linux/skbuff.h:2159-2162。

4. tailroom

概念上：

1	tailroom = end - tail

但本地 5.10 的 skb_tailroom() 对非线性 skb 直接返回 0：

1	return skb_is_nonlinear(skb) ? 0 : skb->end - skb->tail;

见 kernel-5.10/include/linux/skbuff.h:2412-2415。

这是一条重要语义：即使 head buffer 中从 tail 到 end 可能仍有物理空间，也不能简单假定普通 skb_put() 能安全用于非线性 skb。

5. `truesize`

truesize 不是报文长度，而是用于内存计量的近似实际占用。宏 SKB_TRUESIZE() 把以下内容计入：

数据区容量；
对齐后的 struct sk_buff；
对齐后的 struct skb_shared_info。

定义见 kernel-5.10/include/linux/skbuff.h:238-241。

因此：

1	truesize 通常大于 len

后续 socket 内存限制使用的是 truesize，而不是线速包长。

六、一个新 skb 的初始状态

__alloc_skb() 的关键步骤位于 kernel-5.10/net/core/skbuff.c:183-263。

1. 分配 skb shell

1	skb = kmem_cache_alloc_node(cache, ...);

2. 为数据区和 shared info 分配连续内存

1
2
3

size = SKB_DATA_ALIGN(size);
size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
data = kmalloc_reserve(size, ...);

然后用 SKB_WITH_OVERHEAD() 把 shared info 占用从 linear 可用容量中扣除。

3. 初始化四指针/offset

skb->head = data;
skb->data = data;
skb_reset_tail_pointer(skb);
skb->end = skb->tail + size;

所以刚分配完成时：

head == data == tail
len == 0
data_len == 0
headroom == 0
tailroom >= requested size
users == 1
shared_info.dataref == 1

4. 初始化两个不同的引用计数

1 2	refcount_set(&skb->users, 1); atomic_set(&shinfo->dataref, 1);

users 保护 skb shell；
dataref 保护共享 head/data 区。

当前阶段只记住两者不是同一个引用计数；clone 细节放到阶段 4。

七、reserve、put、push、pull 如何改变模型

假设刚分配的 skb 状态为：

1 2	head = data = tail len = 0

1. `skb_reserve(skb, R)`

1
2
3

data += R
tail += R
len 不变

结果是预留 R 字节 headroom。源码明确说明只允许用于空 skb，见 kernel-5.10/include/linux/skbuff.h:2433-2444。

2. `skb_put(skb, N)`

1 2	tail += N len += N

它在尾部扩展 linear data，并返回原 tail 地址供调用者写入，见 kernel-5.10/include/linux/skbuff.h:2291-2299。

3. `skb_push(skb, H)`

1 2	data -= H len += H

它消耗 headroom，在当前数据前增加 H 字节，常用于添加协议头，见 kernel-5.10/include/linux/skbuff.h:2347-2353。

4. `skb_pull(skb, H)`

1 2	data += H len -= H

它越过前 H 字节，使当前视图进入下一层协议，见 kernel-5.10/include/linux/skbuff.h:2355-2361。

示例

初始：
head/data/tail                                           end
    │                                                     │
    +-----------------------------------------------------+

reserve(64)：
head        data/tail                                    end
 │             │                                          │
 +-------------+------------------------------------------+
   headroom=64

put(100)：
head        data                         tail             end
 │             │                           │               │
 +-------------+---------------------------+---------------+
   headroom=64       linear data=100          tailroom

push(20)：
head   data                              tail             end
 │      │                                  │               │
 +------+----------------------------------+---------------+
   44       linear data=120                   tailroom

整个过程中没有搬移原有 payload，只修改地址/offset 和长度。

八、为什么 skb_shared_info 放在 end 后面

源码注释说明 shared info 是跨 clone 共享的不变量，位于 header data 的末尾，见 kernel-5.10/include/linux/skbuff.h:512-515。

这种布局有几个好处：

skb shell 与数据 buffer 可以独立分配和共享；
frag/GSO/dataref 元数据天然跟随共享数据区；
linear 数据可以从前向后增长，直到 end；
skb_shinfo(skb) 可以由 end 直接计算，不需要 skb 额外保存一个 shared-info 指针；
分配器可能给出比请求更大的 kmalloc 块，代码可以把 shared info 放到实际分配区尾部，最大化 linear 可用空间，见 kernel-5.10/net/core/skbuff.c:204-218。

九、生命周期总览

当前只建立高层流程：

分配 skb shell + head buffer
        │
        ▼
reserve headroom
        │
        ▼
put/push 构造数据和协议头
        │
        ▼
驱动 / 协议栈 / Netfilter / qdisc / socket 之间传递或排队
        │
        ├── 可能 clone/copy
        ├── 可能增加 frags/frag_list
        └── 可能绑定 dst/socket/conntrack/destructor
        │
        ▼
consume_skb() 或 kfree_skb()
        │
        ▼
skb_release_head_state() 释放 dst/destructor/conntrack/extensions
        │
        ▼
skb_release_data() 释放 frags/frag_list/head buffer
        │
        ▼
kfree_skbmem() 释放 skb shell

本地释放路径：

kernel-5.10/net/core/skbuff.c:598-626 — head/data 与 frags；
kernel-5.10/net/core/skbuff.c:661-680 — 外部状态和整体释放；
kernel-5.10/net/core/skbuff.c:691-713 — __kfree_skb() / kfree_skb()。

这一流程再次证明：skb shell、外部状态、head buffer 和 frag page 是分层释放的。

十、阶段 0 的关键不变量

不变量 1：四指针顺序

1	head <= data <= tail <= end

如果 push 超过 headroom，可能破坏 head <= data；如果 put 超过 tailroom，可能越过 end。checked API 会做更多检查，但不能依赖非法调用自动恢复。

不变量 2：长度关系

1 2	len >= data_len skb_headlen = len - data_len

__skb_pull() 中存在：

1	BUG_ON(skb->len < skb->data_len);

因为 pull 只能从当前 linear 头部移除数据，不能让总长度小于仍然挂载的非线性长度。

不变量 3：end 指向 shared info 起始位置

1	skb_shinfo(skb) == (struct skb_shared_info *)skb_end_pointer(skb)

任何错误越过 end 的写操作都会破坏 frag、GSO 或引用计数元数据，后果通常不是简单丢一个包，而是内存破坏。

不变量 4：`data` 是动态视图，不是固定协议头

不能看到 skb->data 就假定它永远指向 Ethernet/IP/TCP。必须结合当前调用点以及 MAC/network/transport header offset 判断。

不变量 5：逻辑包长度不等于 linear 长度

1 2	len != tail - data // 非线性 skb 时通常不相等 len == tail - data // 仅可作为纯线性 skb 的典型关系

更通用的关系是：

1	linear length = skb_headlen(skb) = len - data_len

十一、常见误区

误区 1：“struct sk_buff 里面装着整个网络包”

错误。skb 主要保存元数据，linear 数据位于独立 head buffer，payload 还可能在 page 中。

误区 2：“四个成员在所有架构上都是指针”

错误。64 位本地内核中 tail/end 是 offset；四指针是概念模型。

误区 3：“end 是整块分配内存的最后一个字节”

错误。end 是 linear 可用区末尾，后面还有 skb_shared_info。

误区 4：“tail 是整个包的末尾”

错误。对非线性 skb，tail 只是 linear data 的末尾。

误区 5：“len 等于 tail - data”

只对纯线性 skb 成立。非线性 skb 还要包含 data_len。

误区 6：“kfree_skb 就是 kfree(skb)”

错误。它需要先处理 users，释放 dst、destructor、conntrack、extensions、frags、frag_list 和 head buffer，最后才释放 skb shell。

最小生命周期调用链

alloc_skb()/napi_alloc_skb()
→ 初始化 skb shell、linear head 与 skb_shared_info
→ reserve/put/push/pull 建立当前协议视图
→ 协议栈、队列或驱动转移 skb 所有权
→ clone/COW/segment 维护 users、dataref 与 page ref
→ consume_skb()/kfree_skb() 分层释放外部引用、数据区和 shell

字段与所有权统一核对表

对象或字段	表达内容	所有权与释放要点
skb shell / `users`	控制对象及其共享次数	最后一个 shell 引用归零后才释放结构体
head / `dataref`	linear buffer 与尾部 shared info	clone 可共享；最后一个 dataref 释放 head
`frags[]` / page ref	非线性 page payload	shared info 记录片段，free 时逐页归还引用
`frag_list`	子 skb 链	父 skb 持有并在释放路径递归消费
`sk`、dst、nfct	外部子系统状态	各自有独立引用或 destructor，不能由 `users` 代替

2. struct sk_buff 字段地图

结论摘要

struct sk_buff 不应按声明顺序死记。更有效的方式是按“谁在使用字段”分为：队列与调度、设备与 socket、外部引用、长度与数据布局、协议头位置、checksum/offload、流与队列选择、VLAN/隧道、临时控制块、引用计数与扩展九组。字段布局同时承担三类工程目标：热路径访问、结构体空洞填充和 clone 时批量复制。

一、队列与节点字段

struct sk_buff 的开头是：

1 2	struct sk_buff next; struct sk_buff prev;

见 kernel-5.10/include/linux/skbuff.h:720-738。它们必须位于最前面，因为 struct sk_buff_head 的前两个成员同样是 next/prev，见 kernel-5.10/include/linux/skbuff.h:294-301。队列 helper 把 queue head 当作循环双链表哨兵，例如 __skb_queue_head() 会把 (struct sk_buff *)list 传给插入逻辑。

开头的 union 还允许同一块空间作为：

普通 skb 双链表节点；
struct rb_node，供 netem、IPv4 defrag、TCP 等红黑树场景使用；
struct list_head。

关键约束是一个 skb 在同一时刻不能被无约束地同时挂入多种容器；当前持有者必须清楚节点空间的用途。

二、设备、socket 与外部状态

字段	主要语义	生命周期关注点
`dev`	当前输入或输出网络设备	redirect、routing 后可能变化
`sk`	关联 socket	clone 默认不复制 owner；由 destructor 配合记账
`_skb_refdst`	路由/dst 缓存及低位标志	clone 需增加引用，free 时 `skb_dst_drop()`
`destructor`	skb head state 的释放回调	常见为 socket 收发内存回调
`_nfct`	conntrack 引用与状态位	clone/copy/free 必须维护引用
`extensions`	可选 skb 扩展	先检查 `active_extensions`

__copy_skb_header() 明确不复制旧 sk，但会复制 dev、控制块、dst、extensions 和 Netfilter 状态，见 kernel-5.10/net/core/skbuff.c:939-985。因此“复制 skb header”并不等于机械复制整个结构体。

三、长度字段

unsigned int len;
unsigned int data_len;
__u16 mac_len;
__u16 hdr_len;
unsigned int truesize;

len：逻辑包总长度，包含 linear、frags 和 frag_list；
data_len：非线性部分长度；
mac_len：MAC header 长度，通常由 network header 与 MAC header offset 之差得到；
hdr_len：headerless clone 场景记录可写 header 空间；
truesize：内存计量值，不是线速包长。

核心关系：

1 2	skb_headlen(skb) = len - data_len len = linear length + non-linear length

四、协议头字段为什么是 offset

主要字段：

transport_header
network_header
mac_header
inner_transport_header
inner_network_header
inner_mac_header

见 kernel-5.10/include/linux/skbuff.h:900-912。访问 helper 通过 head + offset 得到地址，例如：

1	skb_network_header(skb) = skb->head + skb->network_header;

见 kernel-5.10/include/linux/skbuff.h:2555-2626。

使用 offset 而不是裸指针的主要价值：

data 会被 push/pull，header 位置仍可独立保存；
pskb_expand_head() 可能更换 head buffer，复制 offset 后无需逐个修正绝对指针；
16 位 offset 比 64 位指针节省结构体空间；
inner/outer header 可以同时表达隧道封装。

需要区分：

skb_reset_network_header()：把 network header 设为当前 data；
skb_set_network_header(skb, n)：设为当前 data + n；
skb_network_header()：从 head + offset 取地址。

五、临时控制块 cb[48]

cb[48] 定义于 kernel-5.10/include/linux/skbuff.h:749-755。源码注释给出的所有权规则是：

当前把 skb 排队的层拥有控制块；如果要跨层保留，必须明确复制或保存。

典型 overlay：

IPv4：IPCB(skb) → struct inet_skb_parm，kernel-5.10/include/net/ip.h:47-63,104；
IPv6：IP6CB(skb) → struct inet6_skb_parm；
TCP：TCP_SKB_CB(skb) → struct tcp_skb_cb，kernel-5.10/include/net/tcp.h:838-899；
GRO：NAPI_GRO_CB(skb) → struct napi_gro_cb，kernel-5.10/include/linux/netdevice.h:2487-2554；
qdisc：struct qdisc_skb_cb，kernel-5.10/include/net/sch_generic.h:420-429。

这些结构共享同一 48 字节空间，所以不能同时假设多个 overlay 都有效。进入新子系统时，旧层 cb 内容可能被覆盖。

__copy_skb_header() 使用 memcpy(new->cb, old->cb, sizeof(old->cb)) 复制控制块，但这只保证字节被复制，不保证其跨层语义仍然有效。

六、checksum 与 offload 字段

主要字段包括：

ip_summed；
csum，或 union 中的 csum_start/csum_offset；
csum_valid、csum_level、csum_complete_sw、csum_not_inet；
shared info 中的 gso_size/gso_segs/gso_type。

ip_summed 只有两位，编码 CHECKSUM_NONE/UNNECESSARY/COMPLETE/PARTIAL。它表达的是“checksum 责任和状态”，不是简单的布尔值。GSO 元数据放在 shared info，是因为它属于共享数据布局而不是某个独立 skb shell 的私有队列状态。

七、hash、CPU 与队列字段

字段	用途
`hash`	保存硬件 RSS 或软件 flow dissector hash
`l4_hash`	hash 是否为规范的四元组/L4 hash
`sw_hash`	hash 是否由软件计算
`queue_mapping`	RX/TX 队列映射；TX 时影响 qdisc/设备队列
`napi_id`	RX 来源 NAPI 标识
`sender_cpu`	与 `napi_id` 复用空间，供 XPS 使用
`skb_iif`	输入接口 ifindex

这些字段把“包内容”转换为调度决策：在哪个 CPU 处理、进入哪个 backlog、选择哪个 TX queue。

八、VLAN、隧道和策略字段

protocol：驱动/二层解析得到的上层协议；
vlan_proto/vlan_tci/vlan_present：硬件剥离或 metadata 形式的 VLAN tag；
inner_protocol 与 inner header offset：隧道内层协议；
encapsulation：inner header 是否有效；
mark：策略路由、Netfilter、tc 等通用标记；
priority：排队优先级；
tc_index、tc_skip_classify、tc_at_ingress、redirected：tc 数据路径状态。

注意 union 复用：mark 与 reserved_tailroom 共享空间，napi_id 与 sender_cpu 共享空间。字段当前语义取决于所在路径。

九、headers_start/headers_end 的意义

headers_start 和 headers_end 是零长度数组标记，不保存数据。两者之间的字段在 clone/copy header 时由一次 memcpy() 批量复制，见：

标记：kernel-5.10/include/linux/skbuff.h:798-919；
复制：kernel-5.10/net/core/skbuff.c:954-983。

CHECK_SKB_FIELD() 用编译期断言确保 protocol、checksum、hash、priority、header offset、VLAN、mark 等字段位于批量复制范围内。

这说明字段排列不只是可读性问题，还与复制热路径、空洞和 ABI/KABI 约束相关。queue_mapping 因避免 16 位空洞而留在该区间外，单独复制。

十、结构尾部字段

结构尾部为：

1	tail, end, head, data, truesize, users, extensions

见 kernel-5.10/include/linux/skbuff.h:939-950。__alloc_skb() 只清零到 tail 之前，然后显式初始化尾部，源码还警告不要随意在 tail 后增加字段，见 kernel-5.10/net/core/skbuff.c:221-241。

在 64 位内核中 tail/end 是 offset，head/data 是指针。users 保护 skb shell；共享 head buffer 的引用计数位于 skb_shared_info.dataref。

十一、字段修改者索引

字段组	典型写入者	典型读取者
`dev/protocol`	驱动、`eth_type_trans()`、routing/redirect	RX core、L3、qdisc、driver
header offsets	Ethernet/IP/TCP/隧道 helper	协议解析、checksum、BPF
`hash`	驱动 RSS、flow dissector	GRO、RPS/RFS、socket reuseport
`queue_mapping`	RX 驱动、TX queue selection	qdisc、ndo_start_xmit
checksum	RX driver、协议栈、GSO helper	L3/L4、TX offload
`cb`	当前协议或队列层	同一层后续函数
`sk/destructor`	socket ownership helper	memory accounting/free
dst/nfct/extensions	routing/Netfilter/扩展子系统	output、clone、free

十二、常见误区

skb->data 不是固定协议头；header offset 才保存各层位置。
cb 不是全局稳定元数据，不同层会覆盖它。
queue_mapping 不是 CPU 编号，而是设备 RX/TX queue 语义。
hash 不保证来自硬件，也不保证一定包含 L4 端口。
mark、priority、tc_index 语义不同，不能互换。
headers_start/end 不是缓存行边界，而是批量复制边界。
条件编译会改变结构体实际大小和字段存在性，不能只凭某个配置的 sizeof 推广到所有内核。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`data/tail/end`	分配和 data helper	linear head 布局；shell 私有
`_skb_refdst/_nfct`	路由、Netfilter	引用随 clone/copy/free 转移
`sk/destructor/truesize`	socket owner helper	destructor 归还 socket 记账

最小调用链

alloc/init
→ 子系统写入字段与 header offset
→ queue/protocol/driver 读取
→ clone/copy 复制规定区间
→ free 释放外部引用

结论摘要

skb 数据操作分为三类：移动当前视图的 push/pull，扩展有效数据的 put，预留未来头部空间的 reserve。header helper 用相对 head 的 offset 保存协议头位置。只要操作不重新分配 head，已保存的 header offset 仍有效；pskb_expand_head()、COW、linearize 等可能更换或重排数据，调用者必须遵守 helper 的返回和指针失效规则。

一、基础操作的状态转换

skb_reserve

kernel-5.10/include/linux/skbuff.h:2433-2444：

1 2	skb->data += len; skb->tail += len;

前置条件是空 skb。它不改变 len，只把 headroom 增大、tailroom 减小。典型用途是在构造包之前为 L2/L3/L4 header 或对齐保留空间。

skb_put

checked 版本声明于 kernel-5.10/include/linux/skbuff.h:2291，unchecked __skb_put() 位于 2292-2299：

void *tmp = skb_tail_pointer(skb);
skb->tail += len;
skb->len += len;
return tmp;

它把原 tail 之后的空间纳入 linear data，返回新区域起点。__skb_put() 要求调用者已经证明空间足够，并用 SKB_LINEAR_ASSERT 拒绝非线性 skb。

skb_push

kernel-5.10/include/linux/skbuff.h:2347-2353：

1 2	skb->data -= len; skb->len += len;

它消耗 headroom，用于向前添加 header。调用前必须保证 headroom 足够。

skb_pull

kernel-5.10/include/linux/skbuff.h:2355-2365：

1
2
3

skb->len -= len;
BUG_ON(skb->len < skb->data_len);
skb->data += len;

它只能从 linear 前部移除数据。若 pull 后总长度小于非线性长度，说明试图跨过不存在的 linear 数据，违反不变量。

二、checked 与 unchecked API

带双下划线的 helper 通常省略部分边界检查，适用于上层已证明不变量的热路径。普通 skb_put/push/pull 更适合作为外部 API，但也不能代替调用者理解前置条件。

典型规则：

__skb_put()：必须有足够 tailroom，且 skb 为线性；
__skb_push()：必须有足够 headroom；
__skb_pull()：必须保证 len 合法；
skb_pull_inline()：len > skb->len 时返回 NULL。

错误调用可能不是“返回失败”，而是破坏 shared info 或触发 BUG。

协议解析经常需要保证前 N 字节连续。例如读取完整 IPv4 header 前，不能假定它全部位于 linear 区。

pskb_may_pull() 位于 kernel-5.10/include/linux/skbuff.h:2384-2391：

若 len <= skb_headlen(skb)，直接成功；
若 len > skb->len，失败；
否则调用 __pskb_pull_tail()，从 frags/frag_list 把需要的数据复制或整理进 linear 区。

注意名字中的 pull 不代表它会像 skb_pull() 一样推进 data。它的目标是“保证从当前 data 开始的前 len 字节线性可读”。成功后 skb 布局可能改变，所以调用前缓存的 header 指针应重新获取。

pskb_pull() 则同时保证线性并真正推进 data、减少 len。

四、header offset helper

以 network header 为例：

skb_reset_network_header(skb)
    skb->network_header = skb->data - skb->head;

skb_set_network_header(skb, off)
    skb_reset_network_header(skb);
    skb->network_header += off;

skb_network_header(skb)
    return skb->head + skb->network_header;

见 kernel-5.10/include/linux/skbuff.h:2577-2590。MAC、transport、inner header 使用同样模式。

reset 与 set 的区别

reset：header 就在当前 data；
set(offset)：header 在当前 data 之后 offset；
accessor：从 head 基址计算绝对地址。

push/pull 后 header offset 是否变化

普通 push/pull 只改 data，不会自动改已保存的 header offset。因此：

已保存 header 仍指向原来的字节位置；
当前 data 与 header 的相对距离发生变化；
协议层需要在正确时机 reset/set 对应 header。

这正是 offset 独立于 data 的价值。

以下操作通常不更换 head，仅移动 data/tail：

reserve；
put；
push；
pull。

它们不会使 skb_network_header(skb) 计算出的地址因 head 更换而失效，但调用者缓存的“相对 data 指针”和当前视图语义可能改变。

以下操作可能更换 head 或重排数据：

pskb_expand_head()；
skb_cow_head()；
skb_unclone()；
__pskb_pull_tail()；
skb_linearize()；
BPF change head/adjust room 等。

调用这些函数后，应重新通过 ip_hdr()、tcp_hdr()、skb_network_header() 等 helper 获取指针，不保留旧的 struct iphdr *。

六、pskb_expand_head

实现位于 kernel-5.10/net/core/skbuff.c:1622。它为 head buffer 增加 nhead/ntail，核心步骤包括：

检查 skb shell 不被多个 users 共享；
计算新 head 长度并分配新 buffer；
复制 linear 数据和 shared info；
对 frags、frag_list、zerocopy 和 clone 引用进行必要处理；
根据新 headroom 调整 data、tail、end 和各 header offset；
释放旧数据引用。

它可能改变 skb->head 和 skb->data 的绝对地址，但保持逻辑包内容和 header offset 语义。

不能把它理解成单纯的 realloc()：旧 head 可能被 clone，共享信息和 page refs 必须正确转移。

七、COW：写之前先获得独占数据

skb_cloned

cloned 位只表示“可能共享”，真正判断还需要查看 shared info 的 dataref。这是热路径先看位、再看原子计数的优化。

skb_cow

目标是确保：

需要修改的数据区域可写；
必要 headroom 足够；
若数据被 clone，则扩展/复制得到独占 head。

skb_cow_head

它针对 header 写入场景，常用于 Netfilter NAT、隧道封装、tc/BPF 等将要修改或新增 header 的路径。若 head 已独占且 headroom 足够，返回 0；否则通过 pskb_expand_head() 创建可写 head。

COW 不意味着一定复制全部 payload。非线性 page 可能继续共享，关键是保证要写的 head/header 区域独占。

八、数据操作前置/后置条件表

API	前置条件	主要变化	可能失败	旧指针风险
`skb_reserve`	空 skb、空间足够	data/tail 同时前移	无返回值	data 相关指针变化
`skb_put`	线性、tailroom 足够	tail/len 增加	checked 路径可报错/BUG	原 tail 之后可写
`skb_push`	headroom 足够	data 前移、len 增加	越界会破坏内存	data 变化
`skb_pull`	len 足够、不能越过 linear	data 前移、len 减少	NULL 或 BUG	data 变化
`pskb_may_pull`	请求不超过总 len	必要数据线性化	内存不足返回 false	head/header 指针可能失效
`pskb_expand_head`	skb shell 独占等	更换/扩展 head	`-ENOMEM`	所有绝对数据指针失效
`skb_cow_head`	指定所需 headroom	确保 header 可写	`-ENOMEM`	发生复制时失效

九、典型 RX/TX 使用模式

RX

驱动构造 linear Ethernet frame
→ eth_type_trans() 保存 MAC header 并 pull Ethernet header
→ IP 层 reset network header
→ L4 层 set/reset transport header

TX

先 reserve 足够 headroom
→ 写 payload / skb_put
→ skb_push 添加 L4 header
→ skb_push 添加 IP header
→ skb_push 添加 Ethernet header

真实代码可能使用专用 helper，但四指针变化遵循同一模型。

十、常见误区

pskb_may_pull() 不是普通 skb_pull()，它主要保证连续可读。
push/pull 不会自动替调用者重设所有协议 header offset。
有 cloned 位不等于一定仍共享，必须结合 dataref helper。
COW 不一定复制 frags 中的全部 payload。
pskb_expand_head() 后旧的 iphdr * 不能继续使用。
skb_put() 不是 memcpy；它只把空间纳入有效数据，调用者还需写入内容。
非线性 skb 不能直接按普通 tailroom 追加。

字段与所有权统一核对表

对象或字段	主要修改者/使用者	所有权与释放要点
`data/tail/len`	push/pull/put/trim	调用者持有 skb，操作前必须满足空间不变量
header offsets	reset/set helper	head 重分配后 offset 保持可重定位
`dataref`	COW/expand	共享 head 只有在获得独占可写副本后才能改写

最小调用链

reserve 建立 headroom
→ put/push/pull 改变当前数据视图
→ reset/set 保存 header offset
→ may_pull/COW/expand 保证可访问和可写

源码阅读路线

建议不要从 struct sk_buff 声明开始逐字段背诵，而应使用下面的阅读顺序：

先在入口函数确认 skb 是新分配、clone、队列取出还是从驱动 buffer 构造；
沿成功主线记录 data/len/data_len、header offset、checksum、hash、queue mapping 等字段变化；
再回到每个失败分支，确认 skb、page、DMA、socket 和记账引用是否回滚；
最后对照 5.10、6.1 或 BSP 的同名 symbol，区分语义变化、性能优化和 vendor backport。

本篇总结

skb 是控制对象，包数据可能分散在 linear head、page frags 和子 skb 中。
head <= data <= tail <= end 描述 linear head，不等于整个逻辑包。
协议头使用相对 head 的 offset，因而能够承受 push/pull 和 head 重分配。
读字段时要同时问：谁写入、谁读取、当前谁持有 skb。

系列目录

Linux sk_buff 深度解析（一）：数据结构、四指针与核心字段（本文）
Linux sk_buff 深度解析（二）：非线性数据、引用计数与生命周期
Linux sk_buff 深度解析（三）：从网卡 DMA 到 Socket 的 RX 路径
Linux sk_buff 深度解析（四）：从 sendmsg 到 TX completion
Linux sk_buff 深度解析（五）：GRO、GSO、Checksum 与多核流调度
Linux sk_buff 深度解析（六）：Netfilter、tc、eBPF 与 XDP
Linux sk_buff 深度解析（七）：VLAN、隧道、分片与重组
Linux sk_buff 深度解析（八）：Socket 内存、零拷贝、丢包与版本演进

Linux 内核 NAPI 机制深度解析：从硬中断到软中断轮询

2026-07-14T16:00:00.000Z

写在前面

如果你曾经好奇——网卡每秒收到几十万个包，为什么系统没有崩溃？为什么 Linux 网络栈在高 PPS 下仍能保持吞吐？答案的核心之一就是 NAPI（New API）。

NAPI 不是某个单一函数，而是一套”中断触发、软中断批量轮询、按预算公平调度”的收包负载控制框架。理解它，是读懂 Linux 网络收包路径的必经之路。

本文以 Linux 5.10 为主线，6.1 做对比，结合 e1000 和 RK3588 stmmac 驱动实例，从问题动机到源码细节，完整拆解 NAPI 机制。

一、问题：为什么不能每个包一个硬中断？

千兆/万兆网卡可能每秒产生几十万到数百万个包。如果每个包都触发一次硬中断，CPU 会进入 interrupt livelock——看起来一直忙，但业务处理反而推进很少。具体问题包括：

中断频率过高：CPU 主要时间花在中断入口/出口、寄存器保存恢复、上下文切换上，而不是协议栈本身。
硬中断上下文限制多：不能睡眠，不适合做复杂协议栈处理、内存回收和大批量逻辑。
缓存局部性差：每个包独立打断当前执行流，频繁污染 I-cache/D-cache。
公平性差：一个高流量网卡可能长期占用 CPU，其他软中断、进程调度被拖慢。

NAPI 的解法是：第一次包到达仍靠中断唤醒；进入 NAPI 后，关闭该队列中断，由软中断一次处理一批包，并用 budget 控制单次处理量。

二、核心模型：中断 + 轮询的混合机制

NAPI 不是”纯轮询替代中断”，更准确地说，它是中断触发的自适应批量轮询。基本流程如下：

三种流量下的行为：

流量状态	NAPI 行为
无流量/低流量	网卡硬中断唤醒 CPU，延迟低
流量升高	驱动关闭 RX/TX 中断，把 NAPI 放入 softirq 轮询队列
高流量持续	softirq 不断 poll RX ring，避免每个包再次硬中断
流量下降/本轮清空	`napi_complete_done()` 后重新打开中断，回到低流量中断唤醒模式

以 e1000 为例，中断处理函数 e1000_intr() 读取并清除 ICR，写 IMC 关闭中断，再 __napi_schedule() 调度 NAPI（e1000_main.c:3745）；poll 完成后 e1000_clean() 调用 napi_complete_done()，返回 true 才 e1000_irq_enable()（e1000_main.c:3795）。

三、核心数据结构：`struct napi_struct`

NAPI 的所有状态都围绕 struct napi_struct（include/linux/netdevice.h:330）组织，可按职责分为五类：

3.1 调度和状态字段

字段	说明
`poll_list`	挂到当前 CPU 的 `softnet_data->poll_list` 或临时 `repoll` 链表
`state`	保存 `SCHED`、`MISSED`、`DISABLE` 等状态位
`weight`	单次 poll 的建议预算
`poll`	驱动注册的回调，签名 `int (poll)(struct napi_struct , int)`

3.2 设备关联字段

字段	说明
`dev`	所属 `struct net_device`
`dev_list`	挂入 `dev->napi_list`

3.3 GRO 字段

字段	说明
`gro_hash[]` / `gro_bitmask`	GRO 聚合哈希表与位掩码
`skb` / `rx_list` / `rx_count`	GRO 暂存 skb 链表

NAPI 不只是调度结构，还承载当前 poll 周期内的 GRO 聚合状态。

3.4 定时和延迟开中断字段

字段	说明
`timer`	GRO flush / NAPI watchdog 定时器
`defer_hard_irqs_count`	延迟重新打开硬中断的计数

3.5 netpoll / busy poll 字段

字段	说明
`poll_owner`	`CONFIG_NETPOLL` 下使用
`napi_hash_node` / `napi_id`	busy poll 按 ID 查找 NAPI

3.6 状态位详解

状态位	含义
`NAPI_STATE_SCHED`	已被调度或正在 poll——NAPI 互斥执行的核心位
`NAPI_STATE_MISSED`	poll 期间又来了事件，需要再跑一轮
`NAPI_STATE_DISABLE`	正在禁用，`napi_schedule_prep()` 会拒绝调度
`NAPI_STATE_NPSVC`	netpoll 服务相关，`napi_disable()` 会等待该状态
`NAPI_STATE_IN_BUSY_POLL`	当前由 busy poll 路径持有

核心状态机：

四、驱动如何接入 NAPI

4.1 注册与启用：两步走

第一步——probe 阶段注册 NAPI：调用 netif_napi_add(dev, &priv->napi, poll_fn, weight)。e1000 在 e1000_main.c:1015 注册 adapter->napi，poll 函数为 e1000_clean，weight 为 64。

第二步——open/up 阶段启用 NAPI：调用 napi_enable()，随后打开设备中断。e1000 在 e1000_up() 中先 napi_enable() 再 e1000_irq_enable()。

为什么分两步？注册是把 NAPI 对象初始化并挂到 netdev；启用是设备真正开始运行时解除初始禁用状态。

4.2 `netif_napi_add()` 做了哪些初始化？

该函数（net/core/dev.c:6759）不只是填一个回调，它还把 NAPI 接入 netdev、GRO、timer、busy poll/hash、状态机：

设置 poll、weight、dev
初始化 poll_list、gro_hash、timer（回调为 napi_watchdog）
设置 NAPI_STATE_SCHED 和 NAPI_STATE_NPSVC——让刚注册但尚未 napi_enable() 的 NAPI 处于”不可被正常调度”的初始状态
把 NAPI 挂入 dev->napi_list
加入 NAPI hash，供 busy poll 按 ID 查找

napi_enable() 会清除 NAPI_STATE_NPSVC 和 NAPI_STATE_SCHED，使 NAPI 进入可调度状态。这样可以防止设备尚未 open、ring 尚未准备好时 NAPI 被错误调度。

4.3 open/close 的典型顺序

open/up:
  分配/初始化 ring → 配置硬件 → 清 DOWN 标志
  → napi_enable() → 打开设备中断 → netif_start_queue()

close/down:
  停止发送队列 → 关闭设备中断 → napi_disable()
  → 清理 ring / 释放资源

napi_disable()（net/core/dev.c:6789）设置 NAPI_STATE_DISABLE，并等待 SCHED、NPSVC 状态可被占有，确保没有正在运行或待运行的 NAPI poll。

4.4 多队列网卡：一个 netdev 多个 NAPI

一个 struct net_device 有 napi_list，可以挂多个 struct napi_struct。多队列网卡通常每个 RX queue（或每个 channel）一个 NAPI。

RK3588 SDK 的 stmmac 驱动就是典型例子：stmmac_napi_add() 遍历 queue，对每个 channel 按需注册 rx_napi 和 tx_napi（stmmac_main.c:4963）。

五、从硬中断到软中断：NAPI 调度链路

5.1 核心调度流程

驱动 ISR
  → napi_schedule_prep()          ← 原子状态切换
  → 设置 NAPI_STATE_SCHED 或 MISSED
  → ____napi_schedule()
  → list_add_tail(&napi->poll_list, &sd->poll_list)
  → __raise_softirq_irqoff(NET_RX_SOFTIRQ)
  → net_rx_action()
  → napi_poll()
  → 驱动 napi->poll()

真正把 NAPI 挂入每 CPU softnet_data->poll_list 并触发 NET_RX_SOFTIRQ 的代码是 ____napi_schedule()（net/core/dev.c:4289）。

5.2 `napi_schedule_prep()` 的原子状态机

该函数（net/core/dev.c:6459）循环读取 n->state，计算新状态，用 cmpxchg() 原子替换。逻辑如下：

读取旧状态 val。
如果有 NAPI_STATE_DISABLE，说明设备正在关闭，返回 false。
计算新状态 new = val | SCHED。如果旧状态已经有 SCHED，则额外设置 MISSED。
cmpxchg() 原子替换，失败则并发修改了 state，重试。
返回 !(val & SCHED)：只有原来没被调度时，调用者才应真正入队。

返回值含义：

true：你抢到了从 idle → scheduled 的权利，请入队。
false：已经 scheduled 或 disabled；如果是已 scheduled，MISSED 已记录，不要重复入队。

为什么用原子操作？因为 NAPI 的调度状态可能被多个上下文并发修改：硬中断、softirq poll、busy poll、设备关闭路径、同一设备不同 CPU 上的中断。如果不用原子操作，可能导致同一 NAPI 被重复挂入链表、poll 和 complete 同时改状态导致丢事件。

5.3 MISSED：解决 poll 与中断的竞态

“已经 SCHED” 时再次 schedule，不能重复入 poll_list，也不能丢掉”新事件”。所以设置 NAPI_STATE_MISSED 作为补偿信号。

napi_complete_done()（net/core/dev.c:6502）会检查旧状态是否包含 MISSED。如果包含，它不会回到 idle，而是重新设置 SCHED 并调用 __napi_schedule(n)，返回 false。

poll 期间又来包/事件
  → schedule 发现已 SCHED → 设置 MISSED
  → poll 本轮准备 complete
  → complete 发现 MISSED → 再跑一轮 NAPI

这避免了”poll 刚清空旧事件、准备开中断时，新事件刚好到来但被屏蔽/丢失”的竞态。

5.4 `napi_schedule()` vs `napi_schedule_irqoff()`

两者都先调用 napi_schedule_prep()，区别在入队时是否假设硬中断已经关闭：

版本	说明
`napi_schedule()`	内部 `__napi_schedule()` 会 `local_irq_save()` / `local_irq_restore()`
`napi_schedule_irqoff()`	调用者保证 hard IRQ 已关闭，省掉本地 IRQ 保存恢复

注意：在 CONFIG_PREEMPT_RT 下，__napi_schedule_irqoff() 会退化为 __napi_schedule()，因为 RT 内核中硬中断可能被线程化，”hard IRQ 已关闭”的假设不一定成立。

5.5 为什么 poll 通常运行在触发中断的 CPU 上？

因为 __napi_schedule() 使用 this_cpu_ptr(&softnet_data)，把 NAPI 加到当前 CPU 的 poll_list。好处：

缓存局部性：中断 CPU 刚访问了设备状态、ring 指针和驱动私有数据。
避免跨 CPU 锁竞争：每 CPU poll_list 减少全局队列竞争。
符合 IRQ affinity/RSS 设计：多队列网卡常把不同 RX queue 中断绑到不同 CPU，NAPI 跟随中断 CPU 自然实现并行。

但 RPS/RFS、busy poll、threaded NAPI 等机制可能改变后续处理所在 CPU。

六、`net_rx_action()`：每 CPU 的 NAPI 调度器

net_rx_action() 是 NET_RX_SOFTIRQ 的处理函数（net/core/dev.c:6899），本质是一个每 CPU 的 NAPI 调度器。核心逻辑分 7 段：

取当前 CPU 的 softnet_data。
计算本轮时间上限：当前 jiffies + netdev_budget_usecs。
读取全局包预算 netdev_budget。
关本地中断，把 sd->poll_list 搬到局部 list，减少持有共享队列时间。
循环取 list 上的第一个 NAPI，调用 napi_poll()，从全局 budget 中扣除返回的 work。
如果 budget 用尽或时间到，递增 sd->time_squeeze 并退出本轮。
把新来的 sd->poll_list、repoll 和剩余 list 合并回 sd->poll_list，如果仍有待处理 NAPI，再次 raise NET_RX_SOFTIRQ。

6.1 budget、weight、netdev_budget 三层控制

1
2
3

net_rx_action 总循环受 netdev_budget + netdev_budget_usecs 限制
  每个 napi_poll 又受 napi->weight 限制
    驱动 poll 的入参 budget 通常就是 napi->weight

概念	说明	默认值/典型值
`netdev_budget`	一次 `NET_RX_SOFTIRQ` 总 budget	300（`/proc/sys/net/core/netdev_budget`）
`netdev_budget_usecs`	一次 softirq 的时间上限	2000μs
`napi->weight`	单个 NAPI 每次 poll 的 budget	e1000 为 64，stmmac 为 64

类比：netdev_budget 是总饭票，weight 是单个队列单次最多能拿的饭票。

6.2 repoll 链表

napi_poll() 如果发现驱动返回 work >= weight 且没有 complete，就把该 NAPI 加入 repoll。net_rx_action() 在本轮结束时把 repoll 合并回 sd->poll_list，如果非空则再次 raise NET_RX_SOFTIRQ。

repoll 解决两个问题：

防止单 NAPI 一次调用无限处理（用完 weight 让出机会）。
保留未完成工作（没有 complete 的 NAPI 不丢失）。

6.3 time_squeeze：软中断压力信号

time_squeeze 在全局 budget 用完或时间窗口耗尽时递增。它表示：本 CPU 的 NET_RX softirq 本轮来不及处理完所有待收包工作，被迫提前退出。

如果 /proc/net/softnet_stat 中对应 CPU 的 time_squeeze 持续增长，通常说明：

收包压力较大
netdev_budget 或 netdev_budget_usecs 可能偏小
单 CPU 承担过多 RX queue
中断亲和性/RSS/RPS 配置不均衡

七、驱动 poll 回调：收包的核心战场

7.1 RX ring 生命周期

驱动初始化 RX ring descriptor，分配 DMA buffer
  → 网卡收到包，DMA 写入 buffer，设置 descriptor 状态位（如 DD 位）
  → 网卡产生中断
  → ISR 关闭中断并 schedule NAPI
  → NAPI poll 扫描 RX ring
  → 构造或复用 skb
  → napi_gro_receive() 上交协议栈
  → 补充新的 RX buffer 给 descriptor
  → ring 清空后 complete 并重新开中断

7.2 驱动 poll 的标准模板

int driver_poll(struct napi_struct *napi, int budget)
{
    int work_done = 0;

    clean_tx_irq(...);              /* 清 TX completion */
    clean_rx(..., &work_done, budget); /* 清 RX ring */

    if (work_done < budget) {
        /* RX ring 已清空 */
        if (napi_complete_done(napi, work_done))
            enable_rx_irq();        /* 只有返回 true 才重新开中断 */
    }
    return work_done;
}

关键规则：

返回值 不能超过 budget，否则违反 NAPI 调度契约（napi_poll() 中有检查，超限会打印错误）。
返回 budget → ring 可能还有包，NAPI 不 complete，继续 repoll。
返回小于 budget → 本轮清空，可以 complete 并重新开中断。

注意：如果驱动 poll 正好处理了 budget 个包但 ring 已空，传统 NAPI 语义仍倾向于返回 budget 并让下一轮确认——这是为了避免边界歧义。

7.3 e1000 实例

e1000_clean() 先调 e1000_clean_tx_irq() 清 TX，再调 e1000_clean_rx_irq() 清 RX。后者循环检查 rx_desc->status & E1000_RXD_STAT_DD，用 work_done 与 work_to_do 控制最多处理数量（e1000_main.c:4349）。

7.4 现代 multi-queue 驱动：stmmac

RK3588 SDK 的 stmmac 驱动为每个 channel 注册独立的 RX/TX NAPI：

注册：stmmac_napi_add()
  → 每个 channel: rx_napi + tx_napi

中断调度：stmmac_napi_check()
  → 读 DMA 中断状态
  → RX 事件: disable RX DMA irq + __napi_schedule(&ch->rx_napi)
  → TX 事件: 同理

RX poll：stmmac_napi_poll_rx()
  → stmmac_rx(priv, budget, chan)
  → work_done < budget 且 napi_complete_done() 返回 true → 重开 RX DMA irq

TX poll：stmmac_napi_poll_tx()
  → stmmac_tx_clean() → 完成后重开 TX DMA irq

与 e1000 核心模式一致，但 stmmac 更接近现代多队列/分 RX-TX NAPI 的设计。

八、`napi_complete_done()`：从轮询回到中断的关键同步点

8.1 为什么 `work_done < budget` 才 complete？

因为 work_done < budget 通常表示在预算耗尽前 ring 已无更多包，本轮工作完成，可以退出 polling 模式并重新依赖中断唤醒。

如果 work_done == budget，可能 ring 还有更多包，或刚好处理完但驱动无法可靠区分。保守起见，NAPI 约定不要在返回 budget 时 complete——避免高流量下反复开关中断，也避免边界竞态导致漏处理。

8.2 `napi_complete_done()` 返回 false 时绝不能开中断

返回 false 表示 NAPI 没有真正回到”由硬中断唤醒”的状态。常见原因：

NAPI_STATE_MISSED 存在，已重新 schedule
当前处于 busy poll 状态 NAPI_STATE_IN_BUSY_POLL
配置了 GRO flush timeout / defer hard IRQ，需要延迟开中断
当前处于 netpoll 服务状态 NAPI_STATE_NPSVC

如果驱动不管返回值直接开中断，可能导致 poll 仍在进行时又收到中断、busy poll 语义被破坏、相同事件被双重处理。

所以 e1000 的写法是：只有 napi_complete_done() 返回 true，才 e1000_irq_enable()。

8.3 GRO flush 与 hard IRQ defer

napi_complete_done() 会根据 gro_bitmask、gro_flush_timeout、napi_defer_hard_irqs 决定是否立即 flush GRO、是否启动 NAPI timer、是否返回 false 延迟驱动开中断。

GRO 希望多等一点以便合并更多同流包，提高吞吐。
hard IRQ defer 允许 NAPI 暂时不重新打开硬中断，通过 timer 或后续轮询继续观察。
这是一种吞吐与延迟的折中：延迟开中断提高批处理效率，但可能增加低流量包延迟。

九、GRO：NAPI 承载的批处理优化

NAPI 不只是调度框架，也承载 GRO（Generic Receive Offload）批处理上下文。GRO 相关状态放在 struct napi_struct 中。

9.1 工作原理

1
2
3

NAPI poll 提供批处理时机和上下文
  → GRO 利用这个上下文聚合同流 skb
  → NAPI complete / budget耗尽 / timeout 触发 GRO flush

驱动常调用 napi_gro_receive(napi, skb)（net/core/dev.c:6166）上交包，该函数进入 GRO 逻辑，尝试把同流包合并，最后通过正常收包路径交给协议栈。

9.2 `napi_gro_receive()` vs `netif_receive_skb()`

函数	说明
`netif_receive_skb()`	直接把 skb 交给协议栈收包路径
`napi_gro_receive()`	NAPI 上下文中的 GRO 入口，先尝试聚合，再决定 hold/merge/flush/normal receive

现代高性能驱动应优先使用 napi_gro_receive()，让 TCP/IPv4/IPv6 等流量通过 GRO 降低协议栈处理次数。

十、backlog NAPI：非驱动收包路径

每 CPU 的 softnet_data 中有一个特殊的 backlog NAPI（include/linux/netdevice.h:3307），它不是某个物理网卡队列的 NAPI，而是内核为 backlog 收包队列准备的通用 NAPI 上下文。

两条收包路径的对比：

驱动 NAPI 主路径:
  硬件 RX ring → 驱动 NAPI poll → 构造 skb → napi_gro_receive() → 协议栈

backlog 路径:
  已有 skb → netif_rx()/enqueue_to_backlog()
  → softnet_data input_pkt_queue/process_queue
  → process_backlog() → __netif_receive_skb() → 协议栈

backlog 路径处理已形成 skb 后被放入 CPU backlog 的场景，例如部分虚拟设备、老路径、跨 CPU RPS 入队等。

十一、NAPI 在收包路径中的位置

把 NAPI、RPS/RFS、XDP、page_pool 放在一起看，它们在收包路径中的位置如下：

机制	位置	作用
NAPI	调度框架	调度和执行驱动收包 poll
XDP	驱动 RX 路径，skb 构造前	可 drop/pass/tx/redirect
page_pool	RX buffer 分配/回收	降低 page 分配释放成本
RPS/RFS	skb 存在后，协议栈前	按 flow/hash/socket 亲和性分发到目标 CPU

十二、观测与调优

12.1 关键观测点

观测项	方法
NET_RX softirq 次数	`/proc/softirqs`
dropped / time_squeeze	`/proc/net/softnet_stat`
驱动/网卡队列统计	`ethtool -S`
中断合并参数	`ethtool -c`
全局 budget	`sysctl net.core.netdev_budget`
全局时间限制	`sysctl net.core.netdev_budget_usecs`
NAPI poll tracepoint	`tracepoint:napi:napi_poll`

12.2 ftrace 观察 NAPI poll

mount -t tracefs nodev /sys/kernel/tracing
cd /sys/kernel/tracing

echo 0 > tracing_on
echo > trace
echo 1 > events/napi/napi_poll/enable
echo 1 > tracing_on
# 产生网络流量（如 iperf3）
echo 0 > tracing_on
cat trace

12.3 time_squeeze 持续增长时的排查思路

检查 netdev_budget 和 netdev_budget_usecs 是否偏小。
检查单 CPU 是否承担过多 RX queue（/proc/interrupts）。
检查中断亲和性/RSS/RPS 配置是否均衡。
检查驱动或上层协议栈处理是否过慢。

十三、Linux 5.10 vs 6.1：NAPI 关键差异

维度	Linux 5.10	Linux 6.1
`struct napi_struct`	无 `thread` 字段	增加 `struct task_struct *thread`，支持 threaded NAPI
状态位	无 threaded/busy poll 相关位	增加 `THREADED`、`SCHED_THREADED`、`PREFER_BUSY_POLL`
NAPI 注册 API	`netif_napi_add(dev, napi, poll, weight)`	`netif_napi_add_weight(dev, napi, poll, weight)` + 默认 weight 的 `netif_napi_add()`
`napi_enable()`	inline 实现	变成普通函数实现
`net_rx_action()`	基本框架	主体相似，增加 `skb_defer_free_flush()` 等新逻辑
threaded NAPI	不支持	支持把 NAPI poll 从 softirq 转移到可调度线程

threaded NAPI 的意义：把 NAPI poll 从 softirq 上下文转移到可调度线程，改善实时性控制、允许调度器管理 NAPI 执行、与 PREEMPT_RT 更好配合。代价是线程调度开销和行为复杂度增加，并非所有场景都需要。

迁移注意事项：驱动代码从 5.10 迁移到 6.1 时，netif_napi_add() 参数数量变化，指定 weight 应改用 netif_napi_add_weight()。

十四、总结

回到那句话：NAPI 不是”纯轮询替代中断”，而是”中断触发、软中断批量轮询、按预算公平调度、完成后再开中断”的收包负载控制框架。

理解 NAPI 的四个关键点：

MISSED 状态——理解并发中断与 poll 竞态的核心。
budget 体系——理解 NAPI 公平性和延迟的核心（weight、netdev_budget、netdev_budget_usecs 三层控制）。
napi_complete_done() 返回值——驱动重新打开中断前的关键同步点。
GRO 与 NAPI 的绑定——NAPI 不只是调度框架，也是 GRO 批处理上下文。

NAPI 的核心路径在 net/core/dev.c，但真正理解必须结合一个驱动 poll 函数。建议以 e1000 为入门，再过渡到 stmmac 等现代多队列驱动。

关键源码阅读顺序（Linux 5.10）：

include/linux/netdevice.h:330 — struct napi_struct / NAPI 状态位
include/linux/netdevice.h:454 — napi_schedule() / napi_schedule_irqoff()
net/core/dev.c:6459 — napi_schedule_prep()
net/core/dev.c:4289 — ____napi_schedule()
net/core/dev.c:6899 — net_rx_action()
net/core/dev.c:6833 — napi_poll()
net/core/dev.c:6502 — napi_complete_done()
net/core/dev.c:6759 — netif_napi_add()
drivers/net/ethernet/intel/e1000/e1000_main.c:3795 — e1000_clean()
net/core/dev.c:6166 — napi_gro_receive()

欢迎来到嵌入式开发笔记

2026-07-14T16:00:00.000Z

欢迎来到 嵌入式开发笔记。

这里用于记录 Linux、驱动开发、系统移植、C/C++、设备树以及嵌入式开发中的实践与思考。

内容方向

Linux 内核与驱动开发
U-Boot、设备树与系统移植
C/C++ 编程实践
嵌入式问题定位与调试

代码示例

#include 

int main(void)
{
    puts("Hello, embedded Linux!");
    return 0;
}

嵌入式开发笔记

从一根网线到一个 skb：RK3588 STMMAC 与 RTL8211F 网卡驱动全景解析

一、先拆掉第一个误区：网卡不是一个硬件块

1. MAC：处理以太网帧与 DMA

2. PHY：处理双绞线上的物理信号

3. RGMII：MAC 与 PHY 的数据通道

4. MDIO/MDC：MAC 管理 PHY 的控制通道

二、Linux 为什么把它拆成五层驱动

1. Rockchip glue 不负责逐包收发

2. stmmac 是 MAC 数据路径主体

3. phylink 是 MAC 与 PHY 的合同

4. phylib 提供 PHY 通用状态机

5. Realtek driver 只实现芯片差异

三、从设备树读懂一块板的网口

1. SoC 节点声明 DWMAC 实例

2. 板级 DTS 决定 PHY 和 RGMII 怎么接

3. 不要只看某个 dtsi

四、最危险的板级参数：RGMII delay

1. 为什么 RGMII 需要 delay

2. phy-mode 是从 PHY 视角定义的

3. RTL8211F 会真的读取 phy-mode

4. RK3588 自己也能加 delay

5. RGMII 时序问题的典型症状

五、probe：把一个 DWMAC IP 注册成 Linux 网卡

1. 从 compatible 进入 rk_gmac_probe()

2. 平台层准备什么

3. rk3588_ops 是 SoC 差异接口

4. stmmac_dvr_probe() 创建 Linux netdev

5. net_device_ops 是阅读入口

六、MDIO、PHY ID 与 RTL8211F 驱动绑定

1. stmmac 注册一个 mii_bus

2. DTS reg 必须与 strap 地址一致

3. phylib 用真实 PHY ID 匹配 Realtek driver

4. PHY IRQ 和 MAC IRQ 完全不同

七、phylink：link up 时到底谁配置谁

八、open：什么时候 ring、IRQ 和 DMA 真正开始工作

九、TX：一个 skb 如何变成网线上的帧

1. 调用链

2. ndo_start_xmit 必须完成什么

3. TX completion 不是可选项

4. 常见 TX bug

十、RX：DMA buffer 如何变成 skb

1. 调用链

2. RX 先有 buffer，后有数据

3. stmmac_rx() 的核心职责

4. page 所有权比 skb 更容易出错

十一、IRQ 与 NAPI：为什么中断里不直接把包收完

执行上下文必须分清

十二、DMA 驱动最核心的不是寄存器，而是所有权

1. TX 所有权

2. RX 所有权

3. 为什么需要屏障

4. 为什么不能绕过 DMA API

十三、一个网卡驱动还要照顾哪些“非收发”能力

十四、关闭与挂起：先阻止新工作，再释放资源

十五、故障定位：先判断坏在哪一层

场景 1：驱动没有 probe

场景 2：probe 成功，但找不到 PHY

场景 3：PHY 存在，但 no link

场景 4：link up，但 ping 不通

场景 5：百兆正常、千兆异常

场景 6：高负载丢包、hang 或 TX timeout

十六、推荐的真实开发板 bring-up 路线

第一步：静态硬件闭环

第二步：只验证控制面

第三步：验证链路状态机

第四步：最小数据路径

第五步：性能、温度和电源回归

十七、源码阅读地图

小结

Linux sk_buff 深度解析（八）：Socket 内存、零拷贝、丢包与版本演进

写在前面

阅读前先建立四个问题

本篇核心结论

1. Socket 内存计量与 MSG_ZEROCOPY

结论摘要

一、接收内存

二、发送内存

三、skb_orphan

四、MSG_ZEROCOPY 目标

2. `phy-mode` 是从 PHY 视角定义的

3. RTL8211F 会真的读取 `phy-mode`

1. 从 compatible 进入 `rk_gmac_probe()`

3. `rk3588_ops` 是 SoC 差异接口

4. `stmmac_dvr_probe()` 创建 Linux netdev

5. `net_device_ops` 是阅读入口

1. stmmac 注册一个 `mii_bus`

2. DTS `reg` 必须与 strap 地址一致

2. `ndo_start_xmit` 必须完成什么

3. `stmmac_rx()` 的核心职责