P5-05 · rte_flow offload 实测：SW 匹配 vs HW 卸载，同一个 API

对应路线图：Phase 5 (Day 141-168) ｜ DPDK 24.11.6 LTS ｜ 内核对照 v6.6
代码出处：source/dpdk-stable-24.11.6/lib/ethdev/rte_flow.h、source/linux-stable/net/sched/cls_flower.c
上一篇：P5-04 vDPA ｜ 下一篇：P5-06 DPU 厂商调研

一句话定位

P1-07 学过 rte_flow 的"流与核绑定"，本篇回答另一个问题：同一条 flow rule，由网卡硬件执行还是由 CPU 执行？ API 完全一样（rte_flow_create），区别在 PMD 的 capability 判断——支持就下发硬件（零 CPU），不支持就回退软件匹配（每包吃 CPU）。DPU 的价值主张"把网络处理卸载进硬件"，落到 API 层就是这个开关。

真实源码精读

① 规则三要素：struct rte_flow_attr（lib/ethdev/rte_flow.h:89-129，节选）

struct rte_flow_attr {
    // ...省略 group 的长注释 ...
    uint32_t group;                 // :100 规则组（层级树根在 0）
    uint32_t priority;              // :101 组内优先级
    // ...
    uint32_t ingress:1;             // :105 入向规则
    // ...
    uint32_t egress:1;              // :109 出向规则
    // ...省略 transfer 的长注释 ...
    uint32_t transfer:1;            // :127 转移到设备层（eswitch/representor）
    uint32_t reserved:29;           // :128
};

三个 bit 决定规则贴在哪里：普通 app 用 ingress/egress；DPU/SmartNIC 场景用 transfer:1 把规则下到"设备层"——这就是 OVS 卸载、vDPA 卸载共用的通道。

② pattern 与 action 的枚举（rte_flow.h:153 / :2590）

enum rte_flow_item_type {        // :153
    // ...
    RTE_FLOW_ITEM_TYPE_END,   // :162 列表终止符
    // ...
    RTE_FLOW_ITEM_TYPE_RAW,   // :211 任意字节匹配（几乎只能软件做）
    // ...
    RTE_FLOW_ITEM_TYPE_ETH,   // :218
    // ...
    RTE_FLOW_ITEM_TYPE_VLAN,  // :225
    // ...
    RTE_FLOW_ITEM_TYPE_IPV4,  // :232
    // ...
    RTE_FLOW_ITEM_TYPE_IPV6,  // :239
    // ...
    RTE_FLOW_ITEM_TYPE_UDP,   // :253
    // ...
    RTE_FLOW_ITEM_TYPE_TCP,   // :260

action 侧（:2590 起）：RTE_FLOW_ACTION_TYPE_END（:2597）终止列表，RTE_FLOW_ACTION_TYPE_VOID（:2605）是占位符，往下是 QUEUE/DROP/RSS/COUNT 等。枚举是通用的，能力是各异的——这就是 offload 判断存在的根本原因。

③ 入口签名（rte_flow.h:4694-4699）

struct rte_flow *
rte_flow_create(uint16_t port_id,
        const struct rte_flow_attr *attr,
        const struct rte_flow_item pattern[],
        const struct rte_flow_action actions[],
        struct rte_flow_error *error);

error 参数是调试神器：PMD 拒绝规则时把原因填进去（哪条 item 不支持、哪条 action 不支持），实测时打印 error->message 就能看到自己网卡的 offload 能力边界。

🐧 内核对照：tc flower 的 offload 判断

内核的对应物是 cls_flower（net/sched/cls_flower.c）：fl_change（:2229）处理 tc filter add flower ... 配置，其中 :2369 调用 fl_hw_replace_filter（:452）尝试硬件卸载；卸载失败再走软件分类。和 DPDK 的差别：

同一件事："先试硬件，不行回软件"。内核走配置面 netlink，DPDK 走数据面 API——后者把下发延迟从毫秒级压到微秒级，这正是 DPU 上动态流表需要的。

面试 3 问

1. 怎么判断一条规则最终走了硬件还是软件？ → 查 PMD capability（rte_flow_validate 提前试错）+ rte_flow_create 的 error 明细（rte_flow.h:4694-4699）；实验上对比有/无规则时的 lcore CPU 占用，HW 卸载路径 CPU 几乎不动。
2. transfer:1 属性和普通 ingress 规则区别在哪？ → ingress/egress 规则作用于"到达本端口的流量"，transfer 规则下到设备层端点（eswitch/representor），用于跨物理口/VF 的转发——rte_flow.h:105/109/127 三个 bit 的语义。
3. 为什么 RAW item 几乎只能走软件路径？ → 任意字节匹配不在典型硬件流表能力内（rte_flow.h:211 的 RAW 是"匹配元数据类"item 之一），PMD 无法下发时只能软件逐包比对；5-tuple 类（ETH/IPV4/UDP/TCP，:218/:232/:253/:260）才是硬件卸载的甜区。

🔧 动手实验

本机 82599（ixgbe）offload 能力有限（5-tuple ntuple filter），设计一个"能力边界 + 双路径"实验：

# 1. 起 testpmd，rss 模式跑通
./testpmd -c 0x3 -n 2 -- -i --forward-mode=rxonly

# 2. HW 路径：下发 5-tuple → QUEUE 规则（ixgbe ntuple 能力内）
testpmd> flow create 0 ingress pattern eth / ipv4 src is 10.0.0.1 dst is 10.0.0.2 \
         / udp src is 1234 dst is 5678 / end actions queue index 1 / end
# 观察返回 Flow rule #0 以及 error->message 是否报 unsupported

# 3. SW 路径：换 RAW pattern（ixgbe 不支持硬件匹配）
testpmd> flow create 0 ingress pattern raw relative is 1 pattern is \
         ff:ff:ff:ff:ff:ff:08:00 / end actions queue index 1 / end
# 若 PMD 报 unsupported，记录错误文本；用支持 SW 匹配的路径验证

# 4. 打流对比：dperf 或 pktgen 打目标 5-tuple，
#    对比有规则（HW 卸载）/无规则时 testpmd 的 lcore CPU（mpstat）与 PPS
# 5. 加分项：mlx5 或 dperf 侧做 COUNT action 验证硬件计数

数据落点：perf-data/P5/05-offload.md（flow create 日志与 error 明细、SW/HW 两路径的 PPS 与 CPU 对比、ixgbe 能力边界清单）。预期：ixgbe 上 5-tuple 规则下发成功且 CPU 占用不升（硬件过滤后只剩匹配流量上 CPU）；RAW 规则被明确拒绝——这条"拒绝日志"本身就是能力边界的实证。

下一篇：P5-06 · DPU 厂商调研：BlueField/Pensando/Nitro/国产