linux内核中关于ip分组代码分析逻辑--基于5.4

一、完整调用链

正确调用层级分析（基于Linux 5.15+内核）

1. 网络设备驱动层

   - `netif_receive_skb_list()` // 接收GRO合并的skb链表
     - `__netif_receive_skb_list_core()`
       - `ip_list_rcv()` // IP协议入口链表处理
         - `ip_sublist_rcv()` // 遍历处理每个skb
           - `ip_rcv_core()` // 单包IP头校验
             - `ip_rcv_finish()` // 路由决策
               - `dst_input()` // 根据路由选择输入路径
                 - `ip_local_deliver()` // 本地投递入口

2. IP分片重组路径

ip_local_deliver()
├── if (ip_is_fragment(iph)): // 分片检查
│ └── skb = ip_defrag(net, skb, IP_DEFRAG_LOCAL_DELIVER) // 分片重组
│ ├── ip_find(net, …) // 查找分片队列
│ ├── ip_frag_queue() // 管理分片
│ └── ip_frag_reasm() // 重组完成
└── ip_local_deliver_finish() // 重组后处理
└── ipprot->handler() // 传输层处理（如tcp_v4_rcv）

二、ip_list_rcv代码逐段解析

1. 初始化子链表

struct list_head sublist;
INIT_LIST_HEAD(&sublist); // 初始化临时子链表头

创建临时链表用于分组存储属于同一网络设备的skb
2. 安全遍历主链表

list_for_each_entry_safe(skb, next, head, list) {
    skb_list_del_init(skb); // 原子操作：从主链表摘除skb
    skb = ip_rcv_core(skb, net); // 核心预处理
    if (!skb) continue;        // 无效报文直接丢弃

安全遍历：使用_safe后缀的遍历宏防止链表断裂
原子操作：skb_list_del_init保证链表操作的原子性
核心处理：ip_rcv_core完成：
IP头校验（长度/校验和）
处理IP选项
统计计数更新
3. 设备/网络命名空间分组

if (curr_dev != dev || curr_net != net) { 
    if (!list_empty(&sublist)) 
        ip_sublist_rcv(&sublist, curr_dev, curr_net); // 提交当前子链表
    INIT_LIST_HEAD(&sublist); // 重置子链表
    curr_dev = dev;           // 更新当前设备
    curr_net = net;           // 更新网络命名空间
}
list_add_tail(&skb->list, &sublist); // 添加至当前子链表

分组逻辑：当检测到设备或网络命名空间变化时：
立即处理当前积累的子链表
创建新的分组上下文
设计意图：
减少网络命名空间切换开销
批量处理同设备报文提升缓存利用率
4. 最终提交

ip_sublist_rcv(&sublist, curr_dev, curr_net); // 处理剩余子链表

确保所有skb最终都被处理

三、关键函数说明

1. IP_RCV_CORE()

struct sk_buff *ip_rcv_core(struct sk_buff *skb, struct net *net)

作用：执行IP层的通用接收处理
核心操作：
验证IP版本字段是否为IPv4
检查报文长度是否小于IP头长度
计算并验证IP头校验和
处理IP选项（如需要）

2. IP_SUBLIST_RCV()

static void ip_sublist_rcv(struct list_head *head, struct net_device *dev,
                           struct net *net)

作用：批量提交给上层协议
实现逻辑：
遍历子链表中的每个skb
调用ip_rcv_finish()完成最终处理
通过dst_input()将报文传递给传输层（TCP/UDP等）

四、设计亮点分析

1.批量分组处理：

通过设备/网络命名空间分组，最小化上下文切换
提升CPU缓存命中率（同一设备的报文往往有相似处理路径）

2.无锁设计：

主链表head由分片重组层保证独占访问
使用list_for_each_entry_safe实现安全遍历

3.资源管理：

if (skb == NULL) continue; // 无效报文立即释放

及时释放无效skb避免内存泄漏

4.统计完整性：

错误统计由ip_rcv_core内部完成
通过IP_INC_STATS_BH更新内核计数器

五、ip_list_rcv_finish 数据包进一步处理

函数签名

static void ip_list_rcv_finish(struct net *net, struct sock *sk,
			       struct list_head *head)

• 作用：批量处理IP数据包的接收完成阶段
• 参数：
  • net：网络命名空间（支持容器化网络）
  • sk：关联的socket（可能为NULL）
  • head：待处理的sk_buff链表头

---

核心处理流程

1. 初始化阶段

struct dst_entry *curr_dst = NULL;
struct sk_buff *skb, *next;
struct list_head sublist;

INIT_LIST_HEAD(&sublist);

• curr_dst：缓存当前目标路由条目
• sublist：临时子链表，用于按路由分组处理数据包

---

2. 遍历数据包链表

list_for_each_entry_safe(skb, next, head, list) {
    struct net_device *dev = skb->dev;
    struct dst_entry *dst;

    skb_list_del_init(skb); // 从主链表移除

• 安全遍历：_safe版本允许在遍历时删除节点
• 原子操作：skb_list_del_init确保链表操作的原子性

---

3. L3主设备处理

skb = l3mdev_ip_rcv(skb);
if (!skb)
    continue;

• 功能：如果设备属于L3主设备（如VRF），进行特定处理
• 结果：可能修改或丢弃数据包（返回NULL时跳过后续处理）

---

4. 核心处理逻辑

if (ip_rcv_finish_core(net, sk, skb, dev) == NET_RX_DROP)
    continue;

• 关键函数：ip_rcv_finish_core 完成：
  • 路由查找（ip_route_input_noref）
  • NetFilter NF_INET_PRE_ROUTING 钩子
  • 分片重组检查
• 返回值：NET_RX_DROP表示数据包被丢弃

---

5. 路由分组优化

dst = skb_dst(skb);
if (curr_dst != dst) {
    if (!list_empty(&sublist))
        ip_sublist_rcv_finish(&sublist);
    INIT_LIST_HEAD(&sublist);
    curr_dst = dst;
}
list_add_tail(&skb->list, &sublist);

• 优化策略：将具有相同路由目标（dst_entry）的数据包分组处理
• 优势：
  • 批量提交相同路由的数据包
  • 减少路由缓存失效次数
  • 提升缓存局部性（cache locality）

---

6. 提交最终批次

ip_sublist_rcv_finish(&sublist);

• 最终提交：处理剩余未提交的子链表
• 内部逻辑：对子链表调用dst_input批量处理（本地交付/转发）

---

关键设计亮点

1. 分组处理策略

主链表 → 按路由分组 → 子链表 → 批量提交

• 减少对ip_sublist_rcv_finish的调用次数
• 相同路由的数据包共享路由缓存条目

2. 内存效率

• 使用链表操作而非数组，避免内存拷贝
• skb_list_del_init保持链表完整性

3. 错误隔离

• 单包处理失败不会影响整个批次
• 每个skb有独立的状态管理

---

性能影响点

操作	时间复杂度	备注
l3mdev_ip_rcv	O(1)	设备查找哈希表
ip_rcv_finish_core	O(n)	路由查找可能涉及树遍历
路由分组比较	O(1)	指针比较

---

典型调用场景

1. 接收10个数据包，目标地址分布：
   - 8个发往本地（dst_entry_A）
   - 2个需要转发（dst_entry_B）

2. 处理流程：
   - 前8个进入sublist_A → 一次提交
   - 后2个进入sublist_B → 第二次提交

---

调试技巧

1. 跟踪分组情况：

# 在ip_sublist_rcv_finish处添加tracepoint
echo 1 > /sys/kernel/debug/tracing/events/net/net_dev_queue/enable

2. 统计分组大小：

// 在代码中添加：
pr_info("Sublist size: %d", skb_queue_len(&sublist));

3. 性能分析：

perf record -e cycles:pp -g -- ./vmlinux
# 查看ip_list_rcv_finish的热点分布

---

该实现通过智能分组策略，在保证功能正确性的同时，显著提升了大规模数据包处理场景下的性能表现，特别是在高吞吐量网络设备（如100G网卡）中效果尤为明显。

ip_sublist_rcv_finish 函数的详细解析：

函数签名

static void ip_sublist_rcv_finish(struct list_head *head)

作用：批量提交同一路由目标的数据包到协议栈
设计定位：作为 ip_list_rcv_finish 的辅助函数，实现分组提交优化
参数：
head：包含相同路由目标的 sk_buff 链表头

数据包路由分发

dst_input(skb);

关键路径：

dst_input(skb) 
→ skb_dst(skb)->input(skb)

路由决策：
本地交付：ip_local_deliver
转发：ip_forward
错误处理：ip_error

六、skb_dst(skb)->input(skb)实现

1. skb_dst() 的作用

通过 skb_dst(skb) 获取与 skb 关联的 struct dst_entry 结构体，该结构存储路由信息，其中 input 函数指针决定了数据包的下一步处理逻辑。

2. dst_entry 结构

定义在 include/net/dst.h 中：

struct dst_entry {
    // ...
    int (*input)(struct sk_buff *);
    int (*output)(struct net *, struct sock *, struct sk_buff *);
    // ...
};

• input 函数处理接收方向（本机或转发）
• output 函数处理发送方向

3. input 函数的赋值

路由子系统根据目标地址设置不同的 input 函数：

• 本机接收：设置为 ip_local_deliver

  // net/ipv4/route.c
  if (rt->rt_type == RTN_LOCAL) {
      dst->input = ip_local_deliver;
  }
  

  处理流程：IP层 -> 传输层（TCP/UDP）

• 转发数据包：设置为 ip_forward

  else if (rt->rt_type == RTN_UNICAST) {
      dst->input = ip_forward;
  }
  

  处理流程：查FIB表 -> 转发到出口设备

4. 典型调用路径

// net/ipv4/ip_input.c
int ip_rcv(struct sk_buff *skb, ...) {
    // 路由查找后
    return dst_input(skb); // 最终调用 skb_dst(skb)->input(skb)
}

5. 调试方法

• 动态追踪函数调用：

  perf probe --add 'dst_input skb->dst:struct dst_entry*'
  

• 查看路由缓存：

  ip route show table cache
  

建议结合具体内核版本（如 5.10）查看代码实现，路径集中在：

• net/ipv4/route.c
• net/ipv4/ip_input.c
• include/net/ip_fib.h

七、深度解析调用链的循环疑问ip_local_deliver

核心问题定位

用户观察到的看似"循环调用"现象，实际上反映了 Linux 网络协议栈中 分片重组机制 与 标准接收路径 的协同工作原理。以下用技术细节揭示其内在逻辑：

---

关键函数角色解析

函数名	层级	核心职责
ip_local_deliver()	L3入口	判断报文是否需要分片重组
ip_local_deliver_finish	L3处理	根据协议类型分发到传输层（TCP/UDP等）
ip_defrag()	分片管理	维护分片哈希表，触发重组定时器
ip_frag_reasm()	重组引擎	拼接分片生成完整报文
ip_list_rcv()	重组后入口	将重组后的完整报文重新注入协议栈处理流程

---

生命周期流程图解

---

循环疑问的实质

1. 首次路径（分片状态）：

   驱动收包 → ip_rcv() → ip_local_deliver() → ip_defrag()（缓存分片）
   

   • 此时报文处于 未重组状态
   • 不会立即交付上层协议

2. 重组后路径：

   ip_frag_reasm() → ip_list_rcv() → ip_rcv() → ip_local_deliver() 
   

   • 重组后的完整报文 重新走标准接收流程
   • 此时 ip_defrag() 检查到报文已完整，直接放行

---

设计必要性分析

1. 协议栈状态重置

• 重组后的报文需要：
  • 重新计算校验和
  • 更新长度字段
  • 可能进行策略路由（Policy Routing）
• 示例：分片可能来自不同接口，重组后需要统一路由决策

2. 分层架构约束

• 分片重组模块 (ip_defrag) 设计为 透明中间层
• 重组后的报文应当与普通报文 走相同处理路径
• 保证：

  原始分片路径 ≡ 重组后路径 - 分片处理环节
  

3. 性能优化考量

• 避免为重组报文创建特殊处理通道
• 复用现有路径的缓存预热优势（CPU分支预测、TLB等）

---

代码级验证

在 net/ipv4/ip_input.c 中可见关键逻辑：

// ip_defrag() 内部
if (qp->q.last_in == (FIRST_IN|LAST_IN) &&
    qp->q.meat == qp->q.len) {
    struct sk_buff *head = qp->q.fragments;
    // 触发重组
    ip_frag_reasm(qp, head, dev);
}

// ip_frag_reasm() 末尾
ip_list_rcv(head, NULL, dev, NULL); // 重组后重新注入协议栈

此时 ip_list_rcv 会再次调用 ip_rcv，但关键区别在于：

// ip_rcv() 入口检查
if (ip_is_fragment(ip_hdr(skb))) {
    // 分片路径
    if (ip_defrag(...)) 
        return 0; // 进入重组流程
} else {
    // 正常处理路径
    return NF_HOOK(...);
}

重组后的报文：

• ip_hdr(skb)->frag_off 已被清除分片标志
• ip_is_fragment() 返回 false
• 直接进入正常处理流程，不会再次触发分片处理

---

性能数据佐证

通过内核调试工具验证处理路径：

# 创建分片测试报文
ping -M want -s 3000 127.0.0.1

# 使用 ftrace 跟踪函数调用
echo function > /sys/kernel/debug/tracing/current_tracer
echo ip_rcv ip_local_deliver ip_defrag ip_list_rcv > set_ftrace_filter

# 观察输出（示例）：
# 分片1路径：
ip_rcv() → ip_local_deliver() → ip_defrag()
# 分片2路径：
ip_rcv() → ip_local_deliver() → ip_defrag()
# 重组后路径：
ip_list_rcv() → ip_rcv() → ip_local_deliver()

可见重组后的报文确实重新经过 ip_rcv，但不再进入 ip_defrag

---

架构设计启示

这种看似"循环"的结构体现了两个重要设计原则：

1. 管道-过滤器模式：

   • 每个处理阶段（分片检查、重组、交付）为独立过滤器
   • 报文流经过滤器管道，状态变化驱动路径选择

2. 无状态处理单元：

   • 除分片队列外，各函数不保持中间状态
   • 允许报文多次流经相同函数，但行为由当前报文状态决定

---

总结

该调用链并非真正的循环，而是协议栈为 保持处理路径统一性 所做的设计：

• 首次进入 ip_local_deliver：处理分片报文，进入重组流程
• 重组后进入 ip_local_deliver：处理完整报文，完成最终交付
• 关键区分点：skb->ip_defrag_offset 标志位控制流程分支

这种设计确保了协议栈在处理异常情况（如分片）时，仍能最大程度复用核心处理逻辑，是 Linux 网络栈高可靠性与高性能的重要基础。

八 ip_local_deliver_finish

void ip_protocol_deliver_rcu(struct net *net, struct sk_buff *skb, int protocol)
{
    const struct net_protocol *ipprot;
    int raw, ret;

resubmit:
    // 检查RAW socket处理（原始套接字优先）
    raw = raw_local_deliver(skb, protocol);

    // 通过协议号查找注册的传输层处理程序
    ipprot = rcu_dereference(inet_protos[protocol]);
    if (ipprot) {
        // 安全策略检查（如IPsec）
        if (!ipprot->no_policy) {
            if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb)) {
                kfree_skb(skb); // 策略检查失败时丢弃数据包
                return;
            }
            nf_reset_ct(skb); // 重置连接跟踪状态
        }
        // 间接调用协议处理程序（TCP/UDP等）
        ret = INDIRECT_CALL_2(ipprot->handler, tcp_v4_rcv, udp_rcv, skb);
        if (ret < 0) { // 需要重新提交的情况（如协议重定向）
            protocol = -ret;
            goto resubmit;
        }
        __IP_INC_STATS(net, IPSTATS_MIB_INDELIVERS); // 更新递送统计
    } else {
        if (!raw) {
            // 未知协议处理
            if (xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb)) {
                __IP_INC_STATS(net, IPSTATS_MIB_INUNKNOWNPROTOS);
                icmp_send(skb, ICMP_DEST_UNREACH, ICMP_PROT_UNREACH, 0); // 发送ICMP错误
            }
            kfree_skb(skb); // 释放数据包
        } else {
            __IP_INC_STATS(net, IPSTATS_MIB_INDELIVERS);
            consume_skb(skb); // RAW套接字已消费数据包
        }
    }
}

关键逻辑解析

1. RAW Socket优先处理

   • raw_local_deliver() 检查是否有原始套接字需要处理该协议
   • RAW socket可以绕过常规协议处理，直接接收原始数据包

2. 协议处理程序查找

   • inet_protos[] 是传输层协议注册表（如TCP=6, UDP=17）
   • 通过rcu_dereference安全获取RCU保护的协议处理指针

3. 安全策略检查

   • xfrm4_policy_check() 执行IPsec等安全策略验证
   • nf_reset_ct() 重置Netfilter连接跟踪状态

4. 协议分发机制

   • 使用INDIRECT_CALL_2宏高效调用处理程序（优化分支预测）
   • 典型调用：TCP→tcp_v4_rcv()，UDP→udp_rcv()

5. 错误处理与重试

   • 当处理程序返回负值时，表示需要改变协议重新提交（如ICMP重定向）
   • 通过goto resubmit实现协议类型更新后的重分发

6. 统计与资源管理

   • __IP_INC_STATS更新内核统计计数器
   • 对未知协议发送ICMP协议不可达错误（RFC 1122要求）

设计特点

1. RCU同步机制

   • 整个函数在RCU读临界区运行
   • 保证协议处理程序访问期间协议模块不会被卸载

2. 分层安全控制

   • 先执行Netfilter/XFRM策略检查，后执行协议处理
   • 实现网络安全策略与协议处理的解耦

3. 错误恢复路径

   • 通过协议值负数的特殊处理实现错误恢复
   • 支持协议重定向等高级网络功能

该函数是网络协议栈L3到L4过渡的核心枢纽，其实现体现了Linux内核网络子系统对性能、安全性和扩展性的综合考量。理解这个函数对开发网络过滤模块、实现自定义协议或进行网络栈优化具有重要价值。