当前位置： 首页 > news >正文

DPAA网络驱动深度解析：帧队列、缓冲区池与性能调优实战

news 2026/6/17 18:35:27

1. 项目概述：DPAA驱动的核心机制与价值

在嵌入式网络设备开发领域，尤其是路由器、交换机或高性能网络接口卡，数据包处理的效率直接决定了系统的整体性能。传统上，网络驱动完全依赖CPU进行数据包的接收、分类、处理和发送，这不仅消耗了大量宝贵的CPU周期，也引入了显著的延迟。Freescale（现NXP）为其QorIQ系列处理器引入的数据包分发与加速架构，正是为了解决这一核心矛盾而生的。

DPAA不是一个单一的硬件模块，而是一套完整的片上系统架构，它通过几个关键组件协同工作，将网络数据路径从通用CPU中解放出来。其中，队列管理器负责管理成千上万个硬件队列，帧管理器则处理以太网帧的解析、分类和分发，而缓冲区管理器则高效地管理着数据包缓冲区。这套组合拳的核心思想是“硬件卸载”和“零拷贝”：让专用硬件处理最繁重、最重复的数据搬运和队列管理工作，CPU只需处理高层的协议逻辑和异常情况。

我接触DPAA驱动开发有几年了，从早期的摸索到后来的性能调优，踩过不少坑，也积累了一些实战心得。很多官方文档讲的是“是什么”，但很少告诉你“为什么这么设计”以及“实际配置时要注意什么”。比如，为什么默认要创建128个核心关联队列？静态配置和动态分配帧队列到底该怎么选？共享缓冲区池和私有缓冲区池在性能上究竟有多大差异？这些问题，只有在实际的项目中反复调试和优化才能找到答案。

本文将基于一份经典的SDK文档，深入拆解DPAA以太网驱动中几个最核心也最容易让人困惑的机制：帧队列的配置与管理、缓冲区池的设计与分类，以及如何启用Scatter/Gather、GRO/GSO等高级功能来榨干硬件性能。我会尽量用直白的语言解释背后的原理，并附上我实践中总结的配置要点和避坑指南。无论你是刚开始接触DPAA的驱动工程师，还是正在寻求网络性能突破的系统架构师，相信这些内容都能给你带来直接的帮助。

2. 帧队列详解：数据包的高速公路与交通枢纽

如果把DPAA的数据通路比作一个城市的高速公路网，那么帧队列就是这条路上的各个出入口、匝道和专用车道。每个数据包从网卡进入，到最终被应用程序处理或转发出去，其路径完全由它被放入的帧队列所决定。理解帧队列，是理解DPAA驱动如何工作的第一步。

2.1 帧队列的基本类型与作用

驱动为每个网络接口默认创建一组功能各异的帧队列，它们各司其职，构成了数据包处理的流水线。根据文档，主要包含以下几类：

  1. RX默认队列：这是接收路径的“主入口”。所有未被其他更具体规则（如PCD策略）匹配的入站数据包，都会进入这个队列。你可以把它理解为接收流量的“默认网关”。
  2. RX错误队列：专门接收在接收路径上出错的数据包，比如CRC校验失败、长度错误等。监控这个队列的流量，是诊断物理层或链路层问题的重要手段。
  3. TX确认队列：这是一个非常关键但容易被忽略的队列。当硬件成功发送一个数据包后，会生成一个“发送完成”的通知帧，并放入这个队列。驱动通过处理这个队列中的确认信息，才能知道哪些缓冲区可以被安全地释放或重用。如果这个队列处理不及时，会导致发送缓冲区耗尽。
  4. TX错误队列：与RX错误队列对应，用于接收发送过程中出错的数据包通知。
  5. TX出口队列：这是发送数据包的“出发站”。文档提到驱动默认会创建8个这样的队列，通常与CPU核心数对齐（例如8核CPU就创建8个队列）。驱动可以根据负载均衡策略（如基于流的哈希）将待发送的数据包放入不同的TX队列，从而实现多队列发送，充分利用多核性能。
  6. 核心关联队列：这是一组数量固定（128个）的RX队列，专门用于“核心亲和性”场景。其设计初衷是配合PCD，将特定的数据流（例如某个TCP连接的所有包）哈希到固定的队列上，而这个队列又被绑定到某个特定的CPU核心。这样，从队列中取包处理的线程就会始终在同一颗核心上运行，能极大提升CPU缓存命中率，降低处理延迟。这是实现高性能转发和终止的关键机制之一。

实操心得：刚开始时，我常常混淆TX确认队列和TX出口队列。简单记法：TX出口队列是“我要发送的数据包在这里排队等待上路”；TX确认队列是“我已经上路并到达目的地的数据包，回来告诉我一声，我好打扫车位（释放缓冲区）”。如果发现系统发送吞吐量上不去或出现丢包，一定要先检查TX确认队列的中断和处理是否正常。

2.2 设备树中的静态配置

虽然驱动支持动态分配队列ID，但在产品化部署中，我们更倾向于在设备树中进行静态配置。这样做有几个好处：系统行为可预测、便于跨平台统一管理、方便与固件或其他系统组件（如管理程序）协同工作。设备树中通过两个属性来定义帧队列：

  • fsl,qman-frame-queues-rx：定义接收路径相关的队列。
  • fsl,qman-frame-queues-tx：定义发送路径相关的队列。

每个属性都是一个数组，其基本单元是<base count>对，表示从base这个帧队列ID开始，连续分配count个队列。

对于标准的Linux网络接口，其格式是固定的：<error> <default> [...]。也就是说，数组的第一个条目是错误队列，第二个是默认队列，之后才是其他用途的队列。

让我们看一个文档中的例子，并拆解它：

fsl,qman-frame-queues-rx = <0x100 1 0x101 1 0x180 128>; fsl,qman-frame-queues-tx = <0x200 1 0x201 1 0x300 8>;

  • RX部分 (0x100 1 0x101 1 0x180 128)

    • 0x100 1: RX错误队列，FQID为0x100（十进制256），数量为1。
    • 0x101 1: RX默认队列，FQID为0x101（257），数量为1。
    • 0x180 128: 额外分配的128个RX队列，FQID范围从0x180到0x1FF（384-511）。这通常就是用于核心关联或PCD哈希的那128个队列。注意：文档指出，对于有MAC的接口，RX错误和默认队列是必需的，且数量必须为1。

  • TX部分 (0x200 1 0x201 1 0x300 8)

    • 0x200 1: TX错误队列，FQID为0x200（512）。
    • 0x201 1: TX确认队列，FQID为0x201（513）。
    • 0x300 8: 8个TX出口队列，FQID从0x300开始。文档强调，对于Linux驱动，必须正好是8个，因为它假设每个CPU核心对应一个发送队列。

一个重要的技巧：你可以将base设置为0。这相当于告诉驱动：“这个队列的ID我不指定，请你动态分配一个给我。” 这在早期原型阶段非常有用，可以避免ID冲突，快速验证功能。

2.3 核心关联队列的分配“黑盒”

这是DPAA驱动中一个比较“魔法”的部分。驱动会自动为每个接口创建那128个核心关联队列，并且它们的FQID是硬编码的，计算公式基于MAC寄存器的地址：((MAC register address) & 0x1fffff) >> 6。

文档给出了一个不同SoC和接口的FQID基址表。例如，对于P4080的fm1-gb0接口，基址是0x3800。那么这128个队列的ID就是0x3800,0x3801, ...,0x387F。

这些队列是如何分配到各个CPU核心的呢？驱动采用轮询策略。假设系统有8个核心（core0-core7），那么分配情况如下：

  • FQID 0x3800 -> Core 0
  • FQID 0x3801 -> Core 1
  • ...
  • FQID 0x3807 -> Core 7
  • FQID 0x3808 -> Core 0 （开始第二轮）
  • ... 以此类推。

避坑指南：这个硬编码和轮询机制在文档中被描述为“非常脆弱”，并且计划在未来的版本中修改。这意味着如果你的产品代码依赖这些具体的FQID值或分配顺序，在未来内核版本升级时可能会遇到兼容性问题。一个更稳健的做法是，通过PCD配置文件来定义流量到队列的映射关系，而不是在驱动代码中写死队列ID。理解这个机制主要是为了调试：当你想知道某个数据流被哪个CPU核心处理时，可以反推它进入了哪个FQID，再根据轮询规则找到对应的核心。

3. 缓冲区池：数据包的“停车场”与内存管理艺术

如果说帧队列是道路，那么缓冲区池就是道路两旁停放车辆的“停车场”。所有需要被硬件（FMan）处理的数据包，都必须存放在缓冲区池管理的内存中。DPAA的缓冲区管理器是一个独立硬件模块，它高效地管理着这些缓冲区的分配、释放和回收。

3.1 缓冲区池的配置与分类

缓冲区池可以在设备树中静态定义。每个dpa-ethernet节点可以有一个可选的fsl,bman-buffer-pools属性，它指向一个或多个缓冲区池节点。这些池子节点定义在bman-portals节点下。

一个典型的缓冲区池定义如下：

buffer-pool@1 { compatible = "fsl,p4080-bpool", "fsl,bpool"; fsl,bpid = <1>; // 缓冲区池ID，全局唯一 fsl,bpool-ethernet-cfg = <0 256 0 192 0 0x40000000>; };

关键属性是fsl,bpool-ethernet-cfg，其格式为<count size base_address>，但每个参数都由两个32位数组成，以支持36位或64位地址。上面的例子解读为：

  • count: 256个缓冲区。
  • size: 每个缓冲区192字节。
  • base_address: 内存起始地址为0x40000000。

因此，这个池子占据了从0x40000000到0x40000000 + 256*192的连续物理内存。

驱动将缓冲区池分为两类，这个分类基于内存的所有权和数据传递方式，对性能有直接影响：

  1. 共享池：内存由多个分区（例如，在虚拟化环境中，不同的Guest OS）或系统组件共享。Linux不“拥有”这块内存。当FMan将数据包放入共享池的缓冲区后，驱动必须将数据拷贝到内核的sk_buff结构中，才能继续向上层网络栈传递。这个拷贝操作会消耗CPU周期，影响性能。
  2. 私有池：内存由Linux内核独占拥有。数据包缓冲区本身就是从内核内存中划分出来的。因此，当FMan填充缓冲区后，驱动可以直接将该缓冲区的指针传递给网络栈，无需拷贝，这就是“零拷贝”接收路径的关键，能大幅提升性能。

重要限制：文档明确指出，一个接口不能同时使用两种类型的池。驱动会为使用私有池和共享池的接口创建不同的数据包处理程序。因此，在系统设计初期就要根据场景决定使用哪种池。对于追求极致性能的单一Linux系统，应使用私有池。

3.2 默认私有池的运作机制

对于使用私有池的接口，驱动目前会分配一个全局的默认池供所有这类接口共享。这主要是为了提升缓冲区管理的效率，特别是在IP转发场景下。

试想这样一个场景：数据包从接口A接收，经过Linux内核路由后，需要从接口B发送出去。在理想的零拷贝转发中，我们希望接收缓冲区和发送缓冲区是同一块内存。如果每个接口都有自己的私有池，那么从A的池子拿到的缓冲区，在发给B时，B可能无法使用（因为属于不同池）。而使用一个全局共享的默认私有池，就使得这种“缓冲区跨接口复用”成为可能。FMan可以应驱动请求，将发送接口用过的缓冲区直接返回到这个全局池中，供接收接口再次使用。

这个全局池的缓冲区大小是动态的，由内核配置CONFIG_FSL_FM_MAX_FRAME_SIZE决定，默认是1522字节（标准的1500字节MTU加上以太网帧头、FCS等）。这个值也可以通过内核启动参数fsl_fm_max_frm来覆盖。

池子里的缓冲区数量也不是固定的。因为缓冲区一旦交给内核网络栈，可能被任意修改、重组或长时间持有，不一定能及时归还。为了解决这个问题，驱动采用了一种基于核心的本地计数机制：

  • 每个CPU核心维护一个计数器，记录自己向全局池“放入”和“取出”的缓冲区数量差。
  • 每个核心认为自己负责管理128个缓冲区。
  • 当某个核心的计数器显示它“欠”池子的缓冲区数量低于某个阈值时，该核心就会主动申请内存，向池中补充新的缓冲区。

这种去中心化的设计避免了全局锁竞争，保证了在高并发下缓冲区管理的效率。某个核心的繁忙不会导致整个系统的缓冲区耗尽，因为其他核心会各自维护自己的份额。

4. 高级功能配置与性能调优

DPAA驱动提供了一系列高级功能，可以将特定的网络处理任务进一步卸载到硬件，或者优化内核的数据处理流程。启用这些功能通常需要在编译内核时做出选择，并且理解其适用的场景和限制。

4.1 Scatter/Gather支持

4.1.1 功能原理与启用方式Scatter/Gather是一种I/O技术，允许一个数据块（如一个网络数据包）在物理内存中不必连续存放，而是由一组分散的缓冲区（片段）描述。这对于处理大于单个内存页的数据包，或者实现零拷贝至关重要。

在DPAA驱动中，SG支持在SDK v1.3时引入，但默认是关闭的。要启用它，必须在编译内核时选择针对“终止”场景的优化：

Device Drivers -> Network device support -> Ethernet (10000 Mbit) -> Freescale Data Path Frame Manager Ethernet -> Optimization choices for the DPAA Ethernet driver -> Optimize for termination (CONFIG_DPAA_ETH_OPTIMIZE_FOR_TERM)

选择这个选项后，CONFIG_DPAA_ETH_SG_SUPPORT会被间接启用。

4.1.2 数据路径处理启用SG后，驱动对数据包的处理方式发生了变化：

  • 接收路径：
    • 如果FMan解析器激活且成功解析了帧头，驱动会将帧头内存拷贝到skb的线性部分。
    • 否则，它会拷贝帧的前128字节。
    • 关键优化：接收到的帧的剩余SG片段（如果存在）会直接用作skb的frags，无需拷贝。这是接收路径零拷贝的基础。
  • 发送路径：
    • 对于一个非线性的skb（即由多个片段组成），其线性部分会被拷贝到第一个发送SG缓冲区，而skb的frags则直接作为SG缓冲区使用，无需拷贝。
    • 线性帧的发送则不涉及任何内存拷贝。
    • 另一个关键优化：驱动支持访问分配在高端内存中的发送skb（例如，通过sendfile()系统调用直接从用户空间映射过来的）。这消除了内核需要将这些skb拷贝到低端内存缓冲区的需求，实现了发送路径的零拷贝。

4.1.3 已知限制与注意事项

  1. 每页仅支持一个接收片段：缓冲区池填充的是PAGE_SIZE大小的缓冲区。这意味着一个页面内不能存放多个数据包片段，导致SG模式下缓冲区无法被回收利用，可能会增加内存开销。
  2. 运行时无法切换：SG支持不能通过ethtool在运行时动态开启或关闭，只能在编译时决定。
  3. 场景针对性：SG支持与��为终止优化”的驱动绑定。虽然IP/IPSec转发场景在功能上支持，但其性能落后于为非SG（转发）优化的驱动。因此，如果你的主要场景是路由转发，启用SG可能反而会降低性能。
  4. 需要CONFIG_HIGHMEM：为了获得最佳性能，特别是���用发送零拷贝，必须在内核中启用高端内存支持。

调优建议：SG是一个强大的工具，但并非万能。如果你的应用是服务器类型的“终止”场景（如Web服务器、数据库），处理大量来自外部客户端的连接，并且使用sendfile()等零拷贝API，那么启用SG会带来巨大收益。反之，如果你的设备主要做网络转发（路由器、防火墙），那么使用默认的“为转发优化”的驱动配置可能更合适。

4.2 GRO/GSO支持

4.2.1 功能简介

  • 通用接收卸载：GRO是内核在接收端将多个相似的小数据包合并成一个大的数据包后再提交给网络栈的能力。这减少了协议栈需要处理的数据包数量，降低了CPU占用。DPAA硬件通过校验和卸载、多队列、流量哈希等“GRO辅助”功能来促进软件GRO的效率。
  • 通用分段卸载：GSO是发送端的逆过程。传统上，TCP分段在传输层根据MSS进行。GSO将分段工作推迟到数据即将交给网卡驱动之前，让驱动利用硬件分段能力（如果支持）或由驱动在最后时刻进行软件分段。这减少了协议栈头部的处理开销。

4.2.2 启用与配置和SG一样，GRO/GSO支持也是通过选择CONFIG_DPAA_ETH_OPTIMIZE_FOR_TERM编译选项来默认启用的。不同的是，GRO和GSO可以在运行时通过ethtool独立开关：

# 查看当前卸载功能状态 ethtool -k <interface_name> # 开启GRO ethtool -K <interface_name> gro on # 开启GSO ethtool -K <interface_name> gso on

（注意：需要ethtool版本3.0或更高）

4.2.3 性能调优与局限

  • 收益场景：GRO/GSO在10Gbps流量、小MTU（如1500或更小）的TCP测试中收益最为明显。它能显著降低CPU负载并提升网络吞吐量。当MTU增大到4K以上时，收益几乎不可见。
  • 性能依赖：PCD的支持被强烈推荐。如果驱动检测到没有配置PCD，GRO会被自动绕过。
  • 平台差异：文档明确指出，在P1023平台上，GRO的表现较差。在1Gbps端口上，GRO/GSO带来的好处也很有限。
  • 零拷贝助力：前面提到的SG发送零拷贝（通过sendfile()）能极大提升GSO的性能，因为避免了将大块数据从用户空间拷贝到内核空间再进行分段的过程。

4.3 硬件校验和卸载

FMan硬件支持为特定标准协议计算和验证L3/L4校验和。

  • 发送校验和：支持IPv4/TCP/UDP和IPv6/TCP/UDP。该功能由驱动在每帧的基础上启用。主要前提是帧不能是IP隧道帧（如GRE、IPIP）。
  • 接收校验和：默认禁用。要启用它，必须对相应的接收端口应用PCD策略。在应用PCD后，L3和L4校验和验证会同时对IPv4的TCP和UDP启用。
  • 管理限制：在当前版本中，无法通过ethtool控制此功能。ethtool -k命令会显示该功能不可用，尝试设置会返回错误。

排查技巧：如果你怀疑硬件校验和有问题（例如，TCP连接缓慢或Wireshark显示校验和错误），首先确认是否配置了正确的PCD策略。其次，可以尝试在驱动中暂时禁用此功能（如果允许），用软件校验和进行对比测试，以隔离问题。

5. 设备树与启动参数实战配置解析

理论最终要落地到配置上。DPAA驱动的行为很大程度上由设备树和内核启动参数决定。这里结合文档和实际经验，对一些关键配置项进行深入解析。

5.1 离线端口配置

离线解析/主机命令端口是一个特殊端口，它不直接连接物理MAC，而是用于旁路处理或与协处理器交互。其初始化与在线端口不同：Linux驱动不会初始化它的任何帧队列，仅启用和配置它。

要在设备树中配置一个OH端口，它必须是/fsl,dpaa节点的子节点。一个配置示例如下：

dpa-fman0-oh@1 { compatible = "fsl,dpa-oh"; // 定义OH端口的帧队列：<OH Rx错误队列, OH Rx默认队列> fsl,qman-frame-queues-oh = <0x31e0 1 0x31e8 1>; fsl,fman-oh-port = <&fman0_oh1>; // 指向FMan中的OH端口节点 };

关键点是fsl,qman-frame-queues-oh属性，它只定义两个队列：错误队列和默认队列，格式固定。OH端口的使用通常需要用户空间程序或自定义内核模块通过QMan库直接操作这些队列。

5.2 关键启动参数

  1. fsl_fm_max_frm：设置L2最大帧大小。它直接影响FMan内部FIFO等资源的大小分配。

    • 作用：此值决定了驱动允许设置的最大MTU。最大MTU =fsl_fm_max_frm- 22（22是以太网头+VLAN标签+FCS的典型大小）。
    • 配置方式：
      • 编译时通过CONFIG_FSL_FM_MAX_FRAME_SIZE配置。
      • 启动时通过U-Boot环境变量bootargs添加fsl_fm_max_frm=<值>。
    • 默认与历史：早期SDK默认设为9600以支持巨帧。从v1.0开始，默认改为1522，对应标准1500 MTU。如果需要巨帧，必须显式设置此参数并重启。

  2. fsl_fm_rx_extra_headroom：告诉FMan在接收数据缓冲区的开始处预留额外的空间。

    • 目的：在将内部上下文字段复制到缓冲区之前预留空间。这对于某些需要添加额外头部的场景（如IPSec封装）非常有用，可以避免后续的内存移动。
    • 性能影响：文档指出，默认值（64字节）在转发帧需要封装时性能最佳。对于纯转发或终止场景，推荐设置为0以获得最佳性能，因为任何额外的预留都意味着有效载荷的偏移，可能影响内存访问效率。
    • 缓冲区大小计算：这个参数直接影响USDPAA DTS文件中预分配的缓冲区大小。例如，默认64字节头空间时，缓冲区大小为1728字节（奇数缓存行 * 缓存行大小）。如果设为0，则大小为1600字节。这是一个需要根据应用场景仔细权衡的参数。

5.3 多路复用MDIO配置

在开发板上，由于PHY可能位于不同的子卡上且地址可能冲突，MDIO总线可能被复用。设备树中使用“虚拟”MDIO接口来描述这种配置。每个多路复用器设置被视为一个独立的总线。

mdio0: mdio@e1120 { gpios = <&gpio0 0 0 &gpio0 1 0>; // 控制MUX的GPIO tbi0: tbi-phy@8 { reg = <0x8>; device_type = "tbi-phy"; }; p4080mdio0: p4080ds-mdio0 { #address-cells = <1>; #size-cells = <0>; compatible = "fsl,p4080ds-mdio"; fsl,mdio-handle = <&mdio0>; // 关联到物理MDIO控制器 fsl,muxval = <0>; // MUX设置值 phyrgmii: ethernet-phy@0 { reg = <0x0>; }; }; };

在这个例子中，当MUX值设为0时，p4080ds-mdio0这个虚拟总线才连接到地址为0的RGMII PHY。重要提示：U-Boot会根据硬件配置动态修改设备树，因此DTS中的初始连接关系可能不是最终状态。在调试PHY不通的问题时，需要确认U-Boot最终生成的设备树。

6. 常见问题、排查技巧与版本变迁

6.1 已知问题与应对策略

根据文档，以下是一些已知的限制和问题：

  1. “为终止优化”驱动的性能波动：在某些平台配置或流量模式下（如P1023，或P3/4/5系列仅启用1-2个核心时），启用SG/GRO/GSO的驱动性能可能不如“为转发优化”的驱动，尤其是在帧长小于2K时。对策：根据主要应用场景选择正确的编译优化选项。
  2. QDisc支持被绕过：驱动为了性能，默认绕过了Linux的排队规则支持。这意味着你无法使用tc命令进行流量整形。对策：如果必须使用流量整形，需要修改驱动源码，将DPA_NETIF_FEATURES的定义从NETIF_F_HW_QDISC改为0，然后重新编译内核。
  3. 模块化支持缺失：dpaa_eth驱动目前不支持编译为内核模块，必须内置。
  4. MTU限制：MTU默认最��为1522。如需更大MTU，必须通过fsl_fm_max_frm启动参数设置。
  5. P1023 PCD配置：对于P1023平台，需要使用corenet_pcd.xml，并手动将接口与策略名对应（如fm1-gb0对应policy_fm1_1G_0）。

6.2 自问自答：关键设计抉择

文档最后提出了一些“好问题”，并给出了当时的答案，这些对于理解设计意图非常有帮助：

  • Q：帧队列被分配到哪个通道？
    • A：每个接口在设备树中分配了一个通道。标准Linux设备树将所有接口设置为使用第一个池通道。必需的队列（默认、错误）分配给该通道。8个TX队列分配给与接口关联的TX端口的通道。核心关联队列分配给与其核心关联的通道。其他静态定义的队列以轮询方式分配给核心关联的通道。
  • Q：RX帧队列分配到哪个工作队列？
    • A：目前支持不完善。默认所有帧队列分配给工作队列7。如果FQID是静态分配的，那么FQ将被分配到fqid % 8对应的工作队列。这允许平台架构师通过分配连续的FQID范围来间接选择工作队列。
  • Q：如何使用核心关联队列？
    • A：预期的方式是使用/etc/fmc/config/corenet_pcd.xml中提供的默认配置文件。策略命名规则为：policy_fm<FMAN号>_<端口类型>G_<端口号>。例如，fm1-gb3对应policy_fm0_1G_3。配置好后，使用fmc -c <cfg> -p /etc/fmc/config/corenet_pcd.xml -a命令激活。

6.3 版本变化要点

从更早的版本到SDK v1.3，一些重要的变化包括：

  • 控制最大帧大小的启动参数从fsl_fman_phy_max_frm重命名为fsl_fm_max_frm，并移入了内核菜单配置。
  • 控制额外接收头空间的启动参数fsl_fm_rx_extra_headroom也移入了内核菜单配置。
  • Scatter/Gather支持不再是一个独立的Kconfig选项，而是通过选择“为终止优化”来间接启用。

这些变化表明驱动正在逐步将配置集成到标准的内核配置体系中，使得管理更加统一。在移植或升级驱动时，需要特别注意这些配置项名称和位置的变化。

http://www.jsqmd.com/news/1031237/

相关文章：

  • 从设计矩阵到统计推断：基于SPM12与DPABI的任务态fMRI全流程解析
  • 终极代码搜索工具：CodePilot让开发效率翻倍的完整指南
  • 15-7 反射的应用：动态代理
  • palera1n深度解析：基于checkm8漏洞的iOS越狱高级指南
  • 如何高效使用开源图像查看器ImageGlass：专业级图像管理完整指南
  • 2026年庭院灯厂家深度选型指南：如何为工程匹配最佳方案 - 资讯快报
  • 11-片元着色器（Fragment Shader）完整指南
  • 深入解析CP-SAT混合约束求解引擎：3种架构设计与性能优化实战指南
  • 杭州名表回收商家TOP7榜单，劳力士爱彼变现哪家出价更公道 - 奢品小当家
  • 赣州高口碑黄金铂金回收白银回收实体老店排行 5 家靠谱门店电话地址全收录
  • 双层电感反向旋转的原因（有过孔版）
  • QorIQ PME硬件加速：PMLL库API实战与深度包检测性能优化
  • Dramatron：三步快速掌握AI剧本创作的终极指南
  • 行业内部拆解白皮书：杭州黄金回收定价逻辑，收的顶不玩虚价套路 - 奢侈品回收评测
  • 2026合肥黄金回收实测｜7家正规门店盘点，附品牌金店地址避坑攻略 - 薛定谔的梨花猫
  • 服务器突然变慢？排查系统负载过高的5个实用命令
  • 2026四川高考分数420分志愿怎么填？重庆院校选择思路梳理 - 品牌2026
  • Fcitx5-android模块化输入法框架技术深度解析
  • 一文读懂Grounded SAM核心基础知识
  • 计算机Java毕设实战-基于 Spring Boot 的大学生岗位实习与就业信息服务系统的设计与实现 基于 Spring Boot 的高校实习报【完整源码+LW+部署说明+演示视频，全bao一条龙等】
  • 全屋墙布品牌推荐？米兰软装选购经验分享 - 资讯快报
  • 2026南京闲置名表回收实力排行榜｜正规商家实测甄选，安心变现首选 - 奢侈品回收评测
  • 免疫调控因子组合检测迎来升级 云克隆多因子技术赋能适应性免疫与黏膜免疫研究
  • 新疆小团纯玩咨询前核验清单 - 盛世西域旅行
  • 深耕试题收录工作，打造专业化国家级精品题库 - 936品牌测评网
  • Bongo Cat Mver：5分钟打造你的专属键盘动画伴侣
  • 从界面困扰到高效工作流：ExplorerPatcher如何重塑你的Windows体验
  • 解放设计师双手：Illustrator脚本自动化终极效率革命
  • 芜湖母婴行业企业做GEO应该怎么选服务商？2026靠谱GEO服务商推荐与AI搜索优化实战选型解析 - 科技快讯
  • 杭州哈喽品牌设计有限公司 品牌策划、视觉设计、空间设计 - 资讯快报