DPAA2架构下DPDMUX与DPSECI配置实战：构建高性能网络与安全数据平面

1. 项目概述与DPAA2架构核心价值

在嵌入式网络与安全处理领域，我们常常面临一个核心矛盾：通用CPU的处理能力与日益增长的网络数据包转发、加密解密等计算密集型任务需求之间的巨大鸿沟。尤其是在网关、防火墙、边缘计算节点这类设备上，线速转发和低延迟的加密处理是硬性指标。传统软件方案要么性能捉襟见肘，要么CPU占用率居高不下，导致系统响应迟缓。NXP的Layerscape系列处理器，特别是集成了DPAA2（Data Path Acceleration Architecture 2）架构的型号，正是为解决这一矛盾而生。其核心思想是将数据平面的高速处理任务，如包分类、队列管理、流量整形以及加密解密，卸载到专用的硬件加速引擎上，让CPU专注于复杂的控制平面和管理任务。

DPAA2架构的精髓在于其“硬件对象”模型。你可以把它想象成一个高度模块化的乐高工厂。 DPMAC 是物理或虚拟的网络接口， DPNI 是网络接口对象， DPCON 是消息分发器， DPIO 是队列管理器，而本文要深入探讨的 DPDMUX 和 DPSECI ，则是其中两个至关重要的“功能模块”。 DPDMUX （Data Path Demultiplexer）是一个多路复用/解复用器，它像一个智能的交通枢纽，能够根据MAC地址、VLAN ID等规则，将来自一个上行端口的数据流精准地分发到多个下行端口，或者反之，实现灵活的流量引导和虚拟网络划分。 DPSECI （Data Path SEC Interface）则是连接Linux内核加密子系统与硬件安全引擎（SEC，即CAAM）的桥梁，它将加密API请求无缝卸载到硬件，从而释放CPU。

理解并熟练配置这两个组件，意味着你能够为你的嵌入式设备构建出兼具高性能转发和硬件级安全加速的数据平面。无论是构建一个支持多租户VLAN隔离的工业网关，还是部署一个支持IPSec VPN的网络安全设备，这都是一项必备技能。接下来，我将结合官方文档和一线调试经验，带你从原理到实操，彻底掌握DPDMUX与DPSECI的配置。

2. DPDMUX深度解析与转发模式实战

DPDMUX 是DPAA2中用于流量聚合与分发的核心对象。它最常见的应用场景是模拟一个虚拟的以太网桥或交换机，但比纯软件方案效率高得多，因为它是在硬件层面进行数据包的复制、过滤和转发。

2.1 DPDMUX的三种转发模式及其原理

DPDMUX 支持三种转发方法，对应三种不同的流量识别规则，理解其原理是正确配置的前提。

2.1.1 DPDMUX_METHOD_MAC（基于MAC地址转发） 这是默认的转发模式。其工作原理类似于一个简单的学习型网桥。 DPDMUX 内部维护一个转发表（FDB），记录下行接口（ DPNI ）对应的MAC地址。当数据包从上行端口（通常连接 DPMAC ）进入时， DPDMUX 会检查数据包的目的MAC地址，查询FDB，然后将其转发到对应的下行端口。如果目的MAC不在表中，则进行洪泛（Flood），将该数据包发送给所有下行端口。从下行端口发出的数据包，其源MAC地址会被自动学习并添加到F表中。这种模式适用于简单的二层网络桥接，无需VLAN标签。

2.1.2 DPDMUX_METHOD_C_VLAN（基于客户VLAN标签转发） 这种模式在VEPA（Virtual Ethernet Port Aggregator）模式下使用。它不再关心MAC地址，而是 仅依据数据帧中的VLAN ID（即C-Tag）进行转发 。你需要手动将每个下行端口（如 evb0p0 , evb0p1 ）与一个或多个VLAN ID进行绑定。当带VLAN标签的数据包从上行端口进入时， DPDMUX 会提取其VLAN ID，并只将其转发给绑定了该VLAN ID的下行端口。这实现了严格的基于VLAN的流量隔离，常用于云计算或网络功能虚拟化（NFV）场景，为不同的虚拟机或容器分配独立的VLAN。

2.1.3 DPDMUX_METHOD_C_VLAN_MAC（基于VLAN和MAC地址转发） 这是最精细的转发模式，结合了VLAN和MAC地址两层信息。它通常运行在VEB（Virtual Ethernet Bridge）模式下。在这种模式下， DPDMUX 的转发表是一个二维表，条目是 (VLAN ID, MAC地址) 到下行端口的映射。只有同时匹配VLAN ID和目的MAC地址的数据包才会被转发到指定的端口。这提供了最高级别的流量控制和安全性，可以防止同一VLAN内不同终端之间的非法窥探，常用于需要严格安全策略的环境。

注意：模式选择的核心考量 ：选择哪种模式，取决于你的网络设计需求。如果只是简单的端口聚合，用 MAC 模式；如果需要严格的二层隔离（如多租户），用 C_VLAN 模式；如果需要端口隔离（同一VLAN内主机不能直接通信，流量必须经上行端口由外部路由器或防火墙处理），用 C_VLAN_MAC 模式。 C_VLAN 和 C_VLAN_MAC 模式都依赖于数据包必须携带VLAN标签。

2.2 基于MAC地址的转发配置实操

我们从一个最简单的例子开始，创建一个具有2个下行链路和1个上行链路的MUX，使用默认的MAC地址转发。

# 1. 创建DPDMUX对象，上行端口连接到dpmac.1，指定2个下行端口。
# -b 参数表示以“桥接”模式运行（内部回环）。
# -d=2 指定下行端口数量为2。
# -u=0 指定上行端口索引（这里0代表连接到dpmac.1的那个端口）。
$ ls-addmux -b -d=2 -u=0 dpmac.1

执行成功后，系统会创建一个 dpdmux.0 对象，并生成两个对应的下行接口，通常命名为 evb0p0 和 evb0p1 （ evb0 是聚合接口）。 ls-addmux 这个封装脚本背后，其实是调用了 restool 来创建和连接一系列DPAA2对象。

# 2. 为每个下行端口创建网络接口（DPNI）并关联。
# 这会将dpdmux.0的第一个下行通道与一个DPNI（dpni.1）绑定，并在Linux中呈现为网络接口（例如ni1）。
$ ls-addni dpdmux.0.1
# 同理，绑定第二个下行通道，生成接口ni2。
$ ls-addni dpdmux.0.2

此时，使用 ifconfig -a 或 ip link 命令，应该能看到 ni1 和 ni2 这两个网络接口。

# 3. 配置网络命名空间和接口，用于模拟独立的网络环境。
# 创建网络命名空间ns1和ns2，相当于两个独立的网络沙盒。
$ ip netns add ns1
$ ip netns add ns2

# 将接口ni1移入命名空间ns1，并配置IP地址、启用混杂模式。
$ ip link set ni1 netns ns1
$ ip netns exec ns1 ifconfig ni1 192.168.10.10/24 up
$ ip netns exec ns1 ip link set ni1 promisc on

# 对ni2进行类似操作。
$ ip link set ni2 netns ns2
$ ip netns exec ns2 ifconfig ni2 192.168.10.12/24 up
$ ip netns exec ns2 ip link set ni2 promisc on

配置完成后，在 ns1 中ping ns2 的IP（假设上行端口对端地址是192.168.10.13），即可测试连通性。同时，可以通过 ip -s link show evb0 等命令查看端口的统计信息，确认数据包是否被正确转发。

2.3 基于VLAN标签的转发配置实操

现在，我们来看更常用的基于VLAN的转发配置。这里的关键是创建MUX时指定方法为 DPDMUX_METHOD_C_VLAN ，并且 不 设置桥接选项（即VEPA模式）。

# 1. 创建VLAN转发模式的MUX。
# -v 表示VEPA模式（默认，与-b相对）。
# -m=DPDMUX_METHOD_C_VLAN 指定转发方法。
# -d=2 指定两个下行端口。
$ ls-addmux -v -m=DPDMUX_METHOD_C_VLAN -d=2 dpmac.1

创建MUX和下行接口的步骤与之前类似：

$ ls-addni dpdmux.0.1
$ ls-addni dpdmux.0.2

接下来的配置有所不同，因为我们需要处理VLAN标签。

# 2. 配置带VLAN子接口的网络命名空间。
# 在ns1中，为ni1创建VLAN ID为6的子接口ni1.6，并配置IP。
$ ip netns add ns1
$ ip link set ni1 netns ns1
$ ip netns exec ns1 ip link add link ni1 name ni1.6 type vlan id 6
$ ip netns exec ns1 ifconfig ni1.6 192.168.6.10/24 up
$ ip netns exec ns1 ip link set ni1 up
$ ip netns exec ns1 ip link set ni1 promisc on

# 在ns2中，为ni2创建VLAN ID为7的子接口ni2.7。
$ ip netns add ns2
$ ip link set ni2 netns ns2
$ ip netns exec ns2 ip link add link ni2 name ni2.7 type vlan id 7
$ ip netns exec ns2 ifconfig ni2.7 192.168.7.12/24 up
$ ip netns exec ns2 ip link set ni2 up
$ ip netns exec ns2 ip link set ni2 promisc on

最关键的一步 ：将VLAN ID与物理下行端口绑定。这是告诉 DPDMUX ，哪个端口允许哪个VLAN的流量通过。

# 3. 使用bridge命令将VLAN ID绑定到EVB下行端口。
$ bridge vlan add vid 6 dev evb0p0
$ bridge vlan add vid 7 dev evb0p1

现在，从 ns1 中通过 ni1.6 发送的数据包会携带VLAN 6的标签。当它到达 DPDMUX 时，硬件会根据VLAN ID 6，只将包转发给 evb0p0 （即 ni1 ）。同样，VLAN 7的流量只会走 evb0p1 。你可以通过 bridge vlan show 命令来验证绑定关系。

实操心得：VLAN配置的常见坑点 ：1) 确保物理接口（ ni1 , ni2 ）和VLAN子接口都处于 UP 状态。2) bridge vlan 命令配置的是底层 evb 端口，而不是Linux网络接口 ni1 。3) 在VEPA模式下，同一VLAN内两个下行端口之间的通信 不会 在MUX内部直接转发，而是会发送到上行端口，由外部交换机或路由器处理，这是VEPA与VEB的关键区别。

2.4 基于VLAN和MAC地址的转发配置实操

这种模式提供了端口隔离功能，即使在同一VLAN内，主机也不能直接通信，除非在FDB中明确配置。

# 1. 创建VLAN+MAC转发模式的MUX，通常用于VEB模式。
$ ls-addmux -m=DPDMUX_METHOD_C_VLAN_MAC -d=2 dpmac.1

创建接口和配置VLAN子接口的步骤与 C_VLAN 模式完全相同，这里不再重复。区别在于，我们还需要 手动管理转发数据库（FDB） 。

假设 ni1.6 接口的MAC地址是 4a:64:0a:af:14:a2 ， ni2.7 的MAC地址是 62:9c:86:0f:f7:cf 。

# 2. 向FDB中添加静态条目，指明特定(VLAN, MAC)对应从哪个端口出去。
$ bridge fdb add 4a:64:0a:af:14:a2 dev evb0p0 vlan 6
$ bridge fdb add 62:9c:86:0f:f7:cf dev evb0p1 vlan 7

现在， DPDMUX 的硬件转发表中就有了两条规则：

• 目标MAC为 4a:64:0a:af:14:a2 且VLAN ID为6的帧，从 evb0p0 发出。
• 目标MAC为 62:9c:86:0f:f7:cf 且VLAN ID为7的帧，从 evb0p1 发出。

如果有一个目标MAC不在FDB中，或者VLAN ID不匹配的帧到达，它将被丢弃或转发到上行端口（取决于具体配置），而不会在本地洪泛。这实现了严格的流量控制。

注意事项：MAC地址获取 ：在实际配置中，你需要先 ifconfig ni1.6 up ，然后通过 ip link show ni1.6 来获取其真实的MAC地址，再填入FDB命令。静态FDB条目在系统重启后会丢失，生产环境中可能需要通过脚本在系统启动时自动添加。

3. DPSECI配置与硬件加密加速实战

如果说 DPDMUX 解决了数据流转发的效率问题，那么 DPSECI 就是解决数据安全处理性能瓶颈的利器。它将对称加密、哈希、认证等算法卸载到CAAM硬件引擎。

3.1 DPSECI驱动架构与加载

DPSECI的软件栈分为后端驱动（ dpseci ）和前端驱动（ dpaa2_caam ）。后端驱动负责管理DPSECI硬件对象本身，而前端驱动则作为Linux内核加密API（Cryptographic API）的一个实现，将加密请求翻译并提交给后端。

通常情况下， dpseci 驱动是编译进内核的（built-in），而 dpaa2_caam 驱动则以模块形式提供。因此，第一步是加载前端驱动模块：

$ modprobe dpaa2_caam

加载成功后，可以通过 dmesg | grep dpaa2_caam 查看驱动初始化日志，确认DPSECI对象被成功识别和打开。

3.2 创建与配置DPSECI对象

DPSECI对象需要通过 restool 动态创建，并分配到一个容器（DPRC）中。创建时可以指定队列数量和优先级。

基础创建（使用默认2对队列）：

$ restool dpseci create
$ restool dprc assign dprc.1 --object=dpseci.0 --plugged=1

第一行命令创建了一个DPSECI对象（例如 dpseci.0 ）。第二行命令将这个对象“插入”到指定的容器 dprc.1 中，使其处于可用状态。

高级创建（指定8对队列和优先级）： 为了发挥多核性能和区分业务优先级，我们可以创建更多队列。

$ restool dpseci create --num-queues=8 --priorities=1,2,3,4,5,6,7,8
$ restool dprc assign dprc.1 --object=dpseci.0 --plugged=1

这里 --num-queues=8 指定了8对接收/发送队列。 --priorities 参数为这8个队列分别指定了优先级（1-8，数字越小优先级越高）。加密请求可以根据其类型或QoS被分发到不同优先级的队列中处理。

启用拥塞管理（Congestion Management）： 这是一个重要的性能特性，当MC固件版本 >= 10.2且DPSECI对象版本 >= 5.1时可用。它允许在硬件队列发生拥塞时进行流控，避免丢包。

$ restool dpseci create --num-queues=8 --priorities=1,2,3,4,5,6,7,8 --options="DPSECI_OPT_HAS_CG"
$ restool dprc assign dprc.1 --object=dpseci.0 --plugged=1

在创建命令中加入 --options="DPSECI_OPT_HAS_CG" 即可启用。在高负载加密场景下，强烈建议启用此选项以保障稳定性。

3.3 验证加密算法注册与驱动状态

创建并分配DPSECI对象后，需要确认加密驱动已正确注册算法。

$ grep caam-qi2 /proc/crypto

这条命令会列出所有由 dpaa2_caam 前端驱动注册的加密算法。输出应包含类似以下内容：

name         : cbc(aes)
driver       : cbc-aes-caam-qi2
module       : kernel
priority     : 2000
refcnt       : 1
selftest     : passed
internal     : no
type         : skcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
...

关键字段是 driver 显示为 *-caam-qi2 ，以及 selftest 显示为 passed 。这表明该算法已成功通过内核自检，并且由我们的硬件驱动提供。

排查技巧：如果 /proc/crypto 中没有 caam-qi2 驱动 ：1) 检查 dpaa2_caam 模块是否加载成功（ lsmod | grep dpaa2_caam ）。2) 检查DPSECI对象是否创建并正确分配到DPRC（ restool dpseci info ， restool dprc show dprc.1 ）。3) 检查内核配置，确保 CONFIG_CRYPTO_DEV_FSL_CAAM 和 CONFIG_CRYPTO_DEV_FSL_DPAA2_CAAM 已启用。

3.4 使用tcrypt进行加密性能与功能测试

内核的 tcrypt 模块是测试加密驱动功能的利器。它提供了多种测试模式。

基本功能测试：

# 将编译好的tcrypt.ko模块拷贝到目标板
$ insmod tcrypt.ko mode=10

mode=10 会执行一系列标准算法（如AES-CBC, SHA256）的测试向量验证。模块加载后会自动运行测试并退出。观察内核日志 dmesg ，查看是否有 failed 或 error 信息。测试通过通常不会有明显输出。

性能测试（吞吐量测试）：

# 测试AES-CBC加密算法的速度，测试时长为2秒
$ insmod tcrypt.ko mode=500 sec=2

mode=500 对应AES-CBC等对称加密算法的速度测试。 sec 参数指定测试时间。运行后，内核日志会输出加密操作的吞吐量（如 MB/s ）。这是衡量硬件加速效果最直接的方式。你可以对比在 dpaa2_caam 驱动加载前后，或用软件加密（如 aes-generic 驱动）时的性能差异，通常会有数量级的提升。

中断验证： 硬件加密完成后，SEC引擎会通过DPIO产生完成中断。可以通过监控中断计数来确认硬件是否真的在工作。

$ cat /proc/interrupts | grep DPIO

在运行 tcrypt 测试或真实的加密流量（如IPSec）时，反复执行上述命令，观察对应的DPIO中断计数是否持续增加。如果数字在增长，说明加��请求确实被硬件处理了。

4. IPSec实战：构建硬件加速的VPN隧道

将DPSECI用于实际应用，IPSec VPN是一个经典场景。下面我们以两个LS2088ARDB开发板之间建立IPSec隧道为例，详解配置流程。

4.1 基础环境准备：DPC与DPL配置

DPAA2架构需要两个关键的设备树配置文件：DPC（Data Path Configuration）和DPL（Data Path Layout）。它们定义了MC（Management Complex）启动时的硬件资源分配和拓扑连接。

DPL文件 ( dpl.dts ) ：定义了容器（ dprc ）中包含哪些对象（ dpni , dpmac , dpbp , dpio , dpcon 等）以及它们之间的连接关系。在IPSec测试中，通常需要配置两个 DPNI （对应两个网络接口 ni0 , ni1 ）和多个 DPIO 、 DPCON 来提供足够的队列和消息通道。文档中提供的示例 dpl.dts 创建了一个包含 dpmac@1 、 dpmac@2 、 dpni@0 、 dpni@1 以及一系列支撑对象的容器，并将 dpni@0 连接到 dpmac@1 ， dpni@1 连接到 dpmac@2 。

DPC文件 ( dpc.dts ) ：定义更全局的MC配置，如日志级别、控制台设置、资源池（如ICID池、Buffer Pool数量）等。示例 dpc.dts 主要设置了日志和BMan缓冲区数量。

编译与使用：

$ dtc -O dtb -I dts -o dpc.dtb dpc.dts
$ dtc -O dtb -I dts -o dpl.dtb dpl.dts

将生成的 dpc.dtb 和 dpl.dtb 放入启动分区（如TFTP服务器指定路径），并在U-Boot中通过 fsl_mc apply DPC 和 fsl_mc apply DPL 命令加载，或者直接包含在Linux内核的设备树中。这是让DPAA2硬件按照我们设计的蓝图初始化的关键一步。

4.2 创建DPSECI对象并启用拥塞管理

在Linux系统启动并进入shell后，首先需要创建DPSECI对象。为了获得最佳性能和稳定性，我们创建8对队列并启用拥塞管理。

$ restool dpseci create --num-queues=8 --priorities=1,2,3,4,5,6,7,8 --options="DPSECI_OPT_HAS_CG"
$ restool dprc assign dprc.1 --object=dpseci.0 --plugged=1

请确保 dpaa2_caam 模块已提前加载。

4.3 配置IPSec安全策略与隧道

接下来使用提供的 iproute_128tunnels.sh 脚本（或根据其原理自行配置）来建立大量的IPSec隧道。该脚本的核心是使用 setkey 工具配置安全关联数据库（SAD）和安全策略数据库（SPD）。

脚本为左右两个板子分别配置了64个IPSec隧道。其关键操作包括：

1. 清空现有策略 ： setkey -F 和 setkey -FP 。
2. 定义ESP隧道 ：使用 setkey -c 通过管道添加安全关联（SA），指定加密算法（如 aes-cbc ）、认证算法（如 hmac-sha1 ）和密钥。
3. 定义安全策略 ：指定哪些流量（源/目的IP）需要进入IPSec隧道，以及采取的动作（ require 表示强制使用IPSec）。

例如，脚本中 make_esp_tunnel 函数添加SA， make_esp_policy 函数添加SP。脚本会根据传入的参数 left 或 right ，配置相应的IP地址、ARP条目和路由。

运行脚本： 在左侧板子上执行：

$ ./iproute_128tunnels.sh left

在右侧板子上执行：

$ ./iproute_128tunnels.sh right

4.4 关闭流控与性能测试

在运行流量测试前，一个 至关重要 的步骤是关闭网络接口的流控（Flow Control），或者确保其与对端设备（如测试仪）的设置匹配。不匹配的流控设置会导致缓冲区积压甚至内存损坏。

$ ethtool -A ni0 rx off tx off
$ ethtool -A ni1 rx off tx off

完成所有配置后，就可以使用流量生成器（如Spirent TestCenter）向 ni0 和 ni1 注入IPSec流量。通过监控接口统计信息（ ip -s link ）和系统负载，可以验证IPSec流量是否被成功加解密，并且硬件加速是否生效（观察CPU利用率是否极低，以及 /proc/interrupts 中DPIO中断是否增长）。

5. 常见问题排查与调试技巧实录

在实际部署中，你几乎一定会遇到各种问题。以下是我总结的一些常见故障点和排查思路。

5.1 DPDMUX相关故障

问题1：创建MUX或DPNI失败，提示“Resource busy”或“No such device”。

• 原因A ：对应的 DPMAC 或底层物理端口已被其他DPAA2对象（如另一个 DPNI ）占用。DPAA2对象是独占的。
• 排查 ：使用 restool dprc show dprc.1 查看容器内所有对象及其连接关系。使用 restool dpmac info 查看MAC端口状态。
• 解决 ：销毁冲突的对象（ restool dpni destroy dpni.X ），或修改DPL文件重新分配资源。

问题2：VLAN转发模式不工作，ping不通。

• 原因A ：VLAN ID没有正确绑定到EVB端口。
• 排查 ：执行 bridge vlan show ，确认 evb0p0 、 evb0p1 等端口下是否有预期的 vid 6 、 vid 7 等条目，且状态是否为 PVID 或 Egress Untagged 。
• 原因B ：Linux网络接口的VLAN配置错误。
• 排查 ：在netns内执行 ip -d link show ，确认VLAN子接口（如 ni1.6 ）是否创建成功， vlan id 是否正确。
• 原因C ：数据包没有携带VLAN标签。
• 排查 ：在发送端和接收端用 tcpdump -i ni1 -e 抓包，查看以太网帧中是否包含802.1Q VLAN标签。

问题3： C_VLAN_MAC 模式下，流量不通。

• 原因A ：FDB条目未添加或添加错误。
• 排查 ：执行 bridge fdb show ，检查静态条目是否存在，且MAC地址、VLAN ID、出口设备（ dev evb0p0 ）是否正确。MAC地址必须与对端接口的实际MAC一致。
• 原因B ：接口混杂模式未开启。在某些严格模式下，接口需要接收非本机MAC的帧。
• 排查 ：确认已执行 ip link set ni1 promisc on 。

5.2 DPSECI与加密相关故障

问题1： /proc/crypto 中没有 caam-qi2 驱动。

• 排查步骤 ：
  1. lsmod | grep dpaa2_caam ：确认模块已加载。
  2. dmesg | grep -E “dpaa2_caam|dpseci” ：查看驱动初始化日志，是否有错误。
  3. restool dpseci info ：确认DPSECI对象状态是否为“plugged”。
  4. 检查内核配置：确保 CONFIG_CRYPTO_DEV_FSL_CAAM_QI 和 CONFIG_CRYPTO_DEV_FSL_DPAA2_CAAM 已设置为 y 或 m 。

问题2：tcrypt测试失败，提示“failed to load transform”。

• 原因 ：测试模式尝试测试了DPSECI驱动不支持的算法。
• 排查 ：这是正常现象。 tcrypt 会尝试测试内核注册的所有算法。只需关注驱动实际注册的算法（ grep caam-qi2 /proc/crypto ）测试是否通过。可以指定算法测试，如 insmod tcrypt.ko mode=0 alg="cbc(aes)" 。

问题3：IPSec隧道能建立，但流量速度慢，CPU占用高。

• 原因 ：加密流量没有走硬件加速。
• 排查 ：
  1. 中断法 ：在运行IPSec流量时，持续运行 cat /proc/interrupts | grep DPIO 。如果中断数不增加，说明硬件没干活。
  2. 驱动日志法 ： dmesg 中搜索 dpaa2_caam 初始化时的队列分配信息，确认DPSECI对象版本和队列数量是否正确。
  3. 算法确认 ：使用 ip xfrm state 查看SA详情，确认使用的加密和认证算法（如 cbc(aes) , hmac(sha1) ）是否在 /proc/crypto 中由 caam-qi2 驱动提供。
  4. 密钥长度检查 ：确保IPSec配置的密钥长度在硬件支持范围内（如AES支持128/192/256位）。

5.3 通用调试命令速查表

配置DPAA2的DPDMUX和DPSECI是一个对细节要求极高的过程，任何一个步骤的疏漏都可能导致功能异常。我的经验是，严格按照文档操作，并在每一步之后都用相应的检查命令进行验证，而不是全部配置完再统一测试。尤其是在处理VLAN和FDB时， bridge 命令的配置对象是底层 evb 端口，而非上层的 ni 接口，这个概念一定要清晰。对于加密部分，务必先通过 /proc/crypto 和 tcrypt 验证驱动基础功能，再搭建复杂的IPSec应用，这样可以有效缩小问题范围。当硬件加速生效时，那种极低的CPU占用率和高吞吐量带来的性能提升，会让你觉得这些复杂的配置都是值得的。