TI EMAC驱动开发：描述符队列、中断与缓冲区管理实战解析-拓冰建站

1. 项目概述与核心价值

在嵌入式网络开发，尤其是基于TI处理器平台的项目中，如何高效、稳定地处理海量以太网数据包，是驱动工程师必须啃下的硬骨头。很多开发者初次接触EMAC（以太网媒体访问控制器）时，往往会被其数据手册中复杂的寄存器、描述符和中断机制搞得晕头转向。数据手册提供了标准，但很少告诉你，在实际驱动编写和调试中，哪些细节会“咬人”。今天，我们就来深入拆解TI EMAC/MDIO模块中最为核心的三个机制：描述符队列、中断控制与缓冲区管理。这不是一次照本宣科的翻译，而是结合我多年在工业通信和车载网关项目中的踩坑经验，为你还原一个从硬件机制到软件实现的全景图。无论你是在调试一个吞吐量不达标的网络接口，还是在处理偶发的数据包丢失问题，理解这套“描述符-中断-缓冲区”三位一体的工作流，都将是你解决问题的钥匙。

简单来说，这套机制的核心价值在于将CPU从繁重的数据搬运工作中解放出来，实现高吞吐、低延迟的网络通信。CPU只需要告诉DMA（直接内存访问）引擎“数据在哪里”（描述符），然后就可以去处理其他任务。当DMA完成一批数据的发送或接收后，通过中断“拍一拍”CPU的肩膀：“活儿干完了，来验收一下，顺便把下一批料准备好。” 整个过程高效且异步。下面，我们就从最基础的“零件”——描述符队列开始，一步步搭建起整个认知框架。

2. 描述符队列：硬件与软件的握手协议

描述符（Descriptor）是EMAC模块与软件（驱动）之间进行数据交换的“合同”。它不是一个复杂的概念，你可以把它想象成快递单：上面写着包裹（数据包）放在哪个货架（内存地址）上，包裹有多大，以及当前该由谁（硬件还是软件）来处理这个包裹。

2.1 描述符队列的基本结构

TI EMAC的描述符是一个16字节（4个32位字）对齐的内存结构。它本质上是一个单向链表的节点。每个描述符主要包含两部分信息：

控制信息：指向下一个描述符的指针（pNext）、描述符状态标志位（如SOP, EOP, OWNER等）。
数据缓冲区信息：数据在内存中的地址（pBuffer）、缓冲区长度、数据在缓冲区内的偏移量等。

发送（TX）和接收（RX）描述符格式类似，但标志位含义和由谁设置有所不同，这是理解后续所有操作的基础。

关键设计思想：EMAC硬件并不直接管理一大片连续的内存来存放数据，而是通过遍历一个由软件组装的描述符链表来找到所有数据包碎片。这带来了极大的灵活性——数据包可以分散在内存的任何地方，甚至可以由多个不连续的缓冲区组成一个完整的数据包（即分片，fragmentation）。

2.2 核心标志位深度解析

标志位是描述符的灵魂，是硬件与软件同步的“暗号”。理解每个标志位的设置者、清除者和触发时机，是编写正确驱动的前提。

2.2.1 OWNER 标志位：所有权的交接这是最重要的标志位，它定义了当前描述符（或更准确地说，其关联的数据包）的归属。

谁设置？软件在将一个描述符链表提交给EMAC硬件队列（通过写入HDP寄存器）之前，必须在SOP（Start of Packet）描述符上设置OWNER位。
谁清除？EMAC硬件在完全处理完一个数据包（即处理到该包的EOP描述符）后，会清除对应SOP描述符的OWNER位。
软件如何判断？软件通过轮询或中断后检查描述符链。当发现某个SOP描述符的OWNER位被硬件清除了，软件就知道：“哦，这个包硬件已经处理完了（已发送或已接收），现在缓冲区归我了，我可以回收或填充新数据了。”
一个极易出错的点：OWNER位是以数据包为粒度，而非描述符粒度。这意味着，对于一个多描述符组成的数据包，软件只需要在SOP描述符上设置OWNER，硬件也只在SOP上清除它。EOP或其他中间描述符的OWNER位是无意义的。这简化了软件的状态管理。

2.2.2 SOP/EOP 标志位：数据包的边界这两个标志位共同定义一个数据包的起止。

SOP (Start of Packet)：标记一个数据包的开始。
EOP (End of Packet)：标记一个数据包的结束。
单描述符包：如果整个数据包能放入一个缓冲区，则该描述符的SOP和EOP位同时被设置。
多描述符包：一个数据包被分割到多个缓冲区。第一个描述符设SOP，中间描述符SOP和EOP都不设，最后一个描述符设EOP。
对于发送：SOP/EOP由软件在提交前设置，硬件只读。
对于接收：SOP/EOP初始为0，由硬件在填充数据后根据实际情况设置。

2.2.3 EOQ 标志位：队列耗尽的信号EOQ (End of Queue) 是驱动实现动态追加描述符机制的关键，也是很多“发送卡住”问题的根源。

谁设置？EMAC硬件。
何时设置？当硬件处理一个描述符时，如果同时满足以下两个条件：(a) 该描述符是某个包的EOP；(b) 该描述符的pNext指针为NULL（即链表到此结束），那么硬件就会在这个EOP描述符上设置EOQ标志位。
软件如何利用？软件在中断服务程序或轮询中，检查已释放的描述符（OWNER被清除）。如果发现某个描述符的EOQ位被设置，就意味着：“硬件已经把之前给的活儿全干完了，而且发现没新活儿了，它现在已经停下来了（Halted）。” 此时，软件可以安全地将新的描述符链表追加到队列中。
为什么需要它？防止“追加竞争”。想象一下，硬件正在读取描述符D的pNext指针，此时软件试图将新链表追加到D后面。如果硬件读到的pNext是NULL，它会认为队列结束并设置EOQ。如果软件在硬件读取之后、设置EOQ之前修改了D的pNext，硬件可能无法感知到新链表，导致数据流中断。EOQ机制让软件能可靠地检测到这种“队列耗尽”状态，从而安全地重启队列或追加新描述符。

2.2.4 接收特有的错误标志位接收描述符包含一组丰富的错误标志位（JABBER, OVERSIZE, CRCERROR, ALIGNERROR等），这些都由硬件在接收完成后设置。驱动必须检查这些标志位以进行错误统计和可能的包丢弃处理。例如，CRCERROR标志直接指示帧校验错误，对于要求高可靠性的应用，此类帧应被驱动丢弃并记录错误计数。

2.3 描述符队列的操作流程与实战陷阱

理解了基本零件后，我们来看软件和硬件如何协作操作整个队列。

2.3.1 队列初始化与首次提交

内存分配：软件在内存中分配一批连续的描述符结构体（数组）和对应的数据缓冲区。将每个描述符的pBuffer指向对应的缓冲区，pNext指向下一个描述符，形成链表。最后一个描述符的pNext必须设置为NULL。
描述符状态初始化：对于发送队列，软件设置好SOP/EOP、缓冲区长度、包长度等。对于接收队列，软件只需设置好pBuffer和缓冲区长度（即空缓冲区有多大），并将OWNER位置1（表示缓冲区空闲，归属硬件用于接收），SOP/EOP清0。
提交给硬件：软件将链表第一个描述符的物理地址写入对应通道的头描述符指针寄存器（TXnHDP/RXnHDP）。这个写操作相当于对硬件说：“活来了，从这里开始干！” 写入HDP后，硬件便获得了该链表的所有权（通过OWNER标志识别），并开始处理。

2.3.2 动态追加描述符（核心难点）这是驱动高效运行的关键。我们不可能在初始化时分配无限多的描述符，必须在硬件处理过程中，回收已用完的描述符，并重新填充后追加回队列。

发送侧追加：
1. 软件准备一个新的描述符链表N，其末尾描述符的pNext为NULL。
2. 软件找到当前已被硬件处理完（OWNER=0）且是原链表末尾的描述符（其pNext为NULL）。此时需要检查其EOQ位。
3. 如果EOQ=1：说明硬件已停止，软件可以安全地将链表N的首地址直接写入通道的HDP寄存器，重启发送。
4. 如果EOQ=0：说明硬件可能还在处理中，但尚未读到末尾的NULL。此时，软件可以尝试将链表N的首地址赋值给原末尾描述符的pNext（即“接上”）。这里存在前述的竞争条件，但即使硬件错过了这次追加，它最终也会在原末尾描述符上设置EOQ。软件在后续的中断中检测到EOQ后，再通过写HDP的方式提交新链表即可。这是一种“乐观追加，失败重试”的策略。
接收侧追加：逻辑类似，但目的不同。接收侧是不断将空的缓冲区（描述符）追加到队列尾部，供硬件接收新数据。同样需要关注EOQ标志来安全追加。

2.3.3 实战避坑指南

内存对齐：描述符必须是32位（4字节）对齐的。使用malloc等普通分配函数可能无法保证，需要使用对齐分配函数（如posix_memalign）或在结构体定义时添加对齐属性（如GCC的__attribute__((aligned(4)))）。
缓存一致性（Cache Coherency）：这是嵌入式系统中最隐蔽的Bug来源之一。CPU对描述符和缓冲区的修改都发生在Cache中。如果DMA硬件直接从内存（而非Cache）读取，它将看不到CPU的最新修改，导致数据错误或状态不同步。必须在软件更新描述符并提交给硬件前，将对应的Cache行写回内存（Write-Back）；同样，在硬件更新描述符（如清除OWNER、设置EOQ）后，软件在读取前必须使对应的Cache行失效（Invalidate）。通常使用CP15协处理器指令或平台提供的Cache操作函数（如flush_cache,invalidate_cache）。
描述符回收与重用：回收一个描述符后，在重新填充并提交前，务必将其所有字段（尤其是pNext和标志位）重新初始化。残留的旧数据（如旧的EOQ标志）会导致不可预知的行为。
NULL终止检查：永远确保你提交的任何一个描述符链表的最后一个节点的pNext是NULL。硬件依赖此判断链表结束。

3. 中断机制：高效的事件通知与同步

如果只有DMA和描述符，软件就需要不断轮询（Polling）描述符状态，这无疑是对CPU资源的浪费。中断机制提供了异步通知，让CPU可以“忙自己的事”，等硬件忙完了再来处理。

3.1 中断的产生与判定：CP寄存器的双面角色

TI EMAC的中断逻辑核心围绕一个特殊的寄存器：完成指针寄存器（Completion Pointer, CP，也称为中断应答寄存器）。每个发送和接收通道都有一个对应的TXnCP和RXnCP。

这个寄存器的设计非常巧妙，它扮演了双重角色：

当软件读取它时：它返回一个指针，指向硬件认为它已经处理完成的最后一个描述符。
当软件写入它时：软件写入一个指针，代表软件自己认为它已经处理完成的最后一个描述符。

中断触发条件：当CP寄存器中硬件维护的内部值（软件读到的值）与软件上次写入的值不相等时，该通道的中断状态即为活跃（Active）。简单说，就是“硬件完成的进度”超过了“软件处理的进度”，硬件就会“举手”要求中断。

中断服务程序（ISR）的标准流程：

进入ISR，确定是哪个通道的中断。
读取TXnCP/RXnCP寄存器，获得硬件完成指针hw_ptr。
与软件本地保存的“已处理完成指针”sw_ptr比较。
从sw_ptr的下一个描述符开始，遍历到hw_ptr所指向的描述符（或直到遇到OWNER仍为1的描述符），处理这些描述符关联的数据包（例如，释放已发送的缓冲区，或上交已接收的网络包）。
处理完毕后，将hw_ptr的值写入TXnCP/RXnCP寄存器。这个写操作就是“中断应答”，它告诉硬件：“你刚才通知我的进度，我已经处理完了。” 写入后，硬件内部值与你写入的值相等，中断状态清除。
更新本地的sw_ptr为hw_ptr。

3.2 中断的使能与路由：三层开关

要让一个中断最终到达CPU并触发ISR，需要打开三层“开关”：

EMAC模块级使能：通过设置TXINTMASKSET和RXINTMASKSET寄存器，使能特定通道的发送/接收中断。这是最基础的开关。
EMAC控制模块级使能与路由：EMAC控制模块（Control Module）将多个EMAC/MDIO的中断信号汇总，并路由到最多3个独立的中断核心（Core）。需要通过设置CnTXEN和CnRXEN（n为核心号）等寄存器，将具体的中断类型映射到具体的中断核心输出脉冲上。
CPU中断控制器级使能：最后，需要在CPU的中断控制器（如ARM的GIC）中，配置并使能来自EMAC控制模块的中断线（如Cn_TX_PULSE,Cn_RX_PULSE）。

只有这三层都配置正确，中断才能顺利送达。很多新手驱动跑不通，问题就出在只配置了第一层，忘了后两层。

3.3 中断应答的“双保险”

TI的文档强调，中断服务完成后需要进行两次应答：

对EMAC模块的应答：如前所述，通过写入CP寄存器来完成。这清除了EMAC模块内部的中断状态。
对EMAC控制模块的应答：通过向MACEOIVECTOR寄存器写入一个特定的键值（Key）来完成。这个寄存器像一个“脉冲锁存器”——控制模块发出一个中断脉冲后，在收到对应的应答前，不会发出第二个同类型的中断脉冲。这防止了中断风暴。

正确的ISR退出顺序通常是：先写CP寄存器应答EMAC，再写MACEOIVECTOR应答控制模块。

3.4 中断与轮询的权衡

虽然中断是高效的事件驱动机制，但在极端高负载场景下，频繁的中断本身也会成为开销。因此，一些高性能驱动会采用混合模式：

中断模式：在低负载或常规情况下使用，CPU占用低。
轮询模式（Polling）：在已知会有持续高流量时（如大数据传输），可以暂时关闭中断，由软件在一个紧密循环中主动读取CP寄存器和处理描述符。这虽然增加了CPU占用，但消除了中断上下文切换的开销，能获得更高的吞吐量和更低的延迟。TI EMAC提供了TXINTSTATRAW和RXINTSTATRAW寄存器，即使中断被屏蔽，软件也能通过读取它们来获取原始的中断状态，用于轮询。

4. 缓冲区管理：从描述符到数据包

描述符和中断管理的是“元数据”，而真正的网络数据则存放在缓冲区中。缓冲区管理是驱动性能的另一个关键。

4.1 缓冲区组织策略

单包单缓冲区（One Packet, One Buffer）：最简单的方式，每个数据包无论大小，独占一个固定大小的缓冲区（如2KB）。优点是管理简单，缺点是内存利用率低（小包浪��空间）。
分片（Fragmentation）与聚合（Aggregation）：
- 分片：一个大的数据包由多个描述符及其关联的缓冲区共同描述。这要求软件能处理SOP/EOP标志。对于接收，如果预分配的缓冲区小于到来的数据包，硬件会自动进行分片。
- 聚合：将多个小的数据包放入一个大的缓冲区，由软件解析边界。这通常需要更复杂的软件逻辑，EMAC硬件本身不直接支持聚合。
环形缓冲区（Ring Buffer）与描述符池（Descriptor Pool）：最常用的高效管理方式。驱动初始化时分配一大块内存作为“描述符数组”和另一大块作为“数据缓冲区池”。描述符通过pNext形成链表环。软件维护头尾指针：硬件从“头”取描述符处理，软件从“尾”回收并重新填充描述符。这实现了描述符和缓冲区的循环利用，避免了频繁的内存分配释放。

4.2 发送缓冲区管理实战

数据准备：应用层或协议栈将要发送的数据放入一个内存块。
获取空闲描述符：从发送描述符空闲链表中取出一个或多个描述符。
填充描述符：
- pBuffer指向数据内存块。
- 设置BufOffLen：Buffer Offset（通常为0），Buffer Length（数据长度）。
- 设置PktFlgLen：Packet Length（同Buffer Length，除非分片），设置SOP、EOP标志。如果是新包链表的第一个包，设置OWNER位。
- 设置pNext指向链表中的下一个描述符，最后一个的pNext设为NULL。
提交队列：将链表第一个描述符的物理地址写入TXnHDP，或通过修改前一个链表末尾描述符的pNext来追加。
缓冲区释放：在中断中，检查到OWNER被清除的发送描述符，即可将其使用的数据缓冲区释放回系统，并将描述符本身放回空闲链表。

4.3 接收缓冲区管理实战

预分配空缓冲区：驱动初始化时，将一批描述符的OWNER位置1，pBuffer指向空的、大小合适的缓冲区（如1536字节以适应标准以太网帧），形成链表，写入RXnHDP。这相当于为硬件准备好了“空篮子”。
硬件填充：当网络数据到来，硬件DMA将数据直接写入pBuffer指向的缓冲区，并更新描述符的Buffer Length（实际收到的字节数）、设置SOP/EOP标志，并清除OWNER位。
软件收割：在接收中断中，软件遍历描述符链，找到OWNER被清除的描述符，说明其缓冲区已有数据。软件将数据包上交协议栈。
缓冲区再填充：上交数据后，软件重置该描述符（清空标志位，OWNER重新置1，pBuffer可以指向原缓冲区或新的空缓冲区），并将其追加到接收描述符链表的末尾，等待下一次被硬件使用。

4.4 高级主题：Scatter-Gather DMA

TI EMAC的描述符机制天然支持Scatter-Gather DMA。这意味着一个数据包可以分散在物理内存的多个非连续缓冲区中（通过多个描述符链接），而硬件DMA能够自动地依次从这些分散的缓冲区中收集数据组成一个完整的帧发送出去，或者将接收到的帧分散存放到多个缓冲区。这对于处理网络协议栈的分片/重组（IP Fragmentation/Reassembly）或零拷贝（Zero-copy）网络技术至关重要。

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

即使理解了所有原理，实际调试中依然会遇到各种问题。以下是一些常见症状和排查思路：

5.1 数据发送不出去或接收不到

检查HDP寄存器：确认软件是否正确地将描述符链表的首地址写入了HDP寄存器。使用调试器读取该寄存器，看其值是否为一个合理的、对齐的地址。
检查OWNER标志：在提交发送描述符前，确认SOP描述符的OWNER位是否已置1。对于接收，提交的空描述符OWNER位也应为1。提交后，硬件是否清除了OWNER？如果没有，说明硬件可能根本没有启动或没有访问描述符。
检查描述符链表：确认链表是否完整，最后一个描述符的pNext是否为NULL。使用调试器沿着pNext指针手动遍历链表，看地址是否有效。
检查缓存一致性：这是最隐蔽的问题。确保在硬件访问描述符/缓冲区内存前，软件已执行了正确的Cache写回操作。可以在关键点将关键内存区域设置为非缓存（Non-cacheable）来快速排除Cache问题（牺牲性能换取可调试性）。

5.2 中断不触发

三层开关检查：按照“EMAC模块 -> EMAC控制模块 -> CPU中断控制器”的顺序，逐层检查中断使能位和路由配置是否正确。
检查CP寄存器机制：在ISR中，打印或记录读到的hw_ptr和当前的sw_ptr。确认hw_ptr是否在前进。如果hw_ptr不动，说明硬件没有处理描述符。如果hw_ptr在动但无中断，检查sw_ptr的更新和CP寄存器的写入操作是否正确。
检查中断状态寄存器：读取TXINTSTATRAW/RXINTSTATRAW（原始状态，即使中断被屏蔽），看是否有中断状态位被置起。这能帮你区分是中断产生的问题，还是中断传递/响应的问题。

5.3 数据错乱或覆盖

缓冲区长度溢出：检查描述符中的Buffer Length是否小于或等于实际缓冲区的物理大小。如果硬件试图写入/读取超过缓冲区长度的数据，会导致内存越界，破坏相邻数据。
描述符重用前未重置：回收的描述符在重新放入空闲链表前，必须将其所有字段（特别是pNext和标志位）重置为初始状态。残留的旧数据会导致链表错乱。
并发访问冲突：确保描述符的更新和提交操作在适当的锁或原子操作保护下进行，防止多线程同时修改同一个描述符链。

5.4 性能瓶颈

中断频率过高：对于小包高速率场景，每个包都触发中断会导致CPU负载过高。考虑使用中断合并（Interrupt Coalescing）或切换到轮询模式。TI EMAC控制模块的CnRXIMAX和CnTXIMAX寄存器可以用于设置中断 pacing，限制每毫秒的最大中断数。
描述符处理开销大：在ISR中执行复杂的协议栈处理会延长中断关闭时间。应采用“上半部/下半部”机制，在ISR中只做最少的必要工作（如更新指针、应答中断），将数据包处理等耗时任务放到任务上下文或工作队列中。
内存拷贝开销：避免在驱动层和协议栈之间不必要的内存拷贝。研究并使用零拷贝技术，让协议栈直接处理DMA缓冲区中的数据。

调试时，逻辑分析仪或示波器可以帮你确认MDIO时钟和数据线是否有活动，以判断PHY是否被正确访问。而内存查看工具则是你洞察描述符和缓冲区状态的最好朋友。养成在关键节点（如提交描述符后、进入ISR时）主动dump描述符内存区域的习惯，将内存中的二进制数据与你的数据结构定义对照，很多问题会一目了然。

6. 从理论到实践：一个简化的驱动框架示例

为了将上述所有概念串联起来，这里给出一个极度简化但体现核心流程的发送/接收伪代码框架，帮助你建立整体认知。

// 描述符结构定义（需对齐） typedef struct _EMAC_Desc { struct _EMAC_Desc *pNext; // 物理地址 uint8_t *pBuffer; // 物理地址 uint32_t BufOffLen; uint32_t PktFlgLen; } __attribute__((aligned(4))) EMAC_Desc; // 全局队列管理结构 typedef struct { EMAC_Desc *desc_base; // 描述符数组基地址 void *buf_base; // 数据缓冲区池基地址 EMAC_Desc *free_head; // 空闲描述符链表头 EMAC_Desc *hw_tail; // 硬件可能处理到的尾部（用于追加） EMAC_Desc *sw_processed; // 软件已处理的指针（用于CP比较） } ChanCtx; ChanCtx tx_ctx, rx_ctx; // 初始化描述符和缓冲区池 void desc_pool_init(ChanCtx *ctx, int num_desc, int buf_size) { // 1. 分配对齐的描述符内存和数据缓冲区内存 // 2. 初始化每个描述符：pBuffer指向对应的缓冲区，pNext指向下一个描述符形成链表 // 3. 最后一个描述符的pNext = NULL // 4. 设置ctx->free_head指向链表头 // 5. 对于接收描述符，设置OWNER=1，表示空闲，可供硬件接收数据 } // 发送一个数据包 int eth_send_packet(void *data, int len) { // 1. 从tx_ctx.free_head获取一个空闲描述符desc // 2. 准备数据缓冲区（可能是拷贝或零拷贝） // 3. 填充desc: // desc->pBuffer = data_phy_addr; // desc->BufOffLen = (0 << 16) | (len & 0xFFFF); // offset=0 // desc->PktFlgLen = (EMAC_DSC_FLAG_SOP | EMAC_DSC_FLAG_EOP | EMAC_DSC_FLAG_OWNER) | (len & 0xFFFF); // desc->pNext = NULL; // 4. 缓存一致性操作：将desc写回内存 // 5. 将描述符提交给硬件： // if (当前发送队列为空) { // write_reg(TX0HDP, desc_phy_addr); // 首次提交，写HDP // } else { // // 追加到现有队列 // EMAC_Desc *tail = find_tail_desc(); // 找到当前队列最后一个描述符 // if (tail->PktFlgLen & EMAC_DSC_FLAG_EOQ) { // // 硬件已停止，安全重启 // write_reg(TX0HDP, desc_phy_addr); // } else { // // 尝试追加 // tail->pNext = desc; // flush_cache(&tail->pNext); // 关键！确保硬件能看到新指针 // } // } // 6. 更新上下文 return 0; } // 发送中断服务例程 void tx_isr(void) { // 1. 读取完成指针 uint32_t hw_cp = read_reg(TX0CP); // 2. 从sw_processed开始，遍历到hw_cp指向的描述符 EMAC_Desc *desc = tx_ctx.sw_processed; while (desc != hw_cp) { // 检查OWNER是否被清除 if (!(desc->PktFlgLen & EMAC_DSC_FLAG_OWNER)) { // 发送完成，回收缓冲区，将描述符放回空闲链表 // 注意检查EOQ标志，用于队列状态判断 if (desc->PktFlgLen & EMAC_DSC_FLAG_EOQ) { // 记录队列已停止，后续提交可能需要写HDP } reclaim_desc_to_free_pool(desc); } desc = desc->pNext; // 注意：这里需要将物理地址转换为虚拟地址再访问 } // 3. 应答中断：将hw_cp写回CP寄存器 write_reg(TX0CP, hw_cp); // 4. 更新软件指针 tx_ctx.sw_processed = hw_cp; // 5. 应答EMAC控制模块中断 write_reg(MACEOIVECTOR, TX_INT_ACK_KEY); } // 接收中断服务例程（类似，但处理数据包上交） void rx_isr(void) { uint32_t hw_cp = read_reg(RX0CP); EMAC_Desc *desc = rx_ctx.sw_processed; while (desc != hw_cp) { if (!(desc->PktFlgLen & EMAC_DSC_FLAG_OWNER)) { // 数据已就绪 int pkt_len = desc->PktFlgLen & 0xFFFF; void *pkt_data = desc->pBuffer + (desc->BufOffLen >> 16); // 考虑offset // 将数据包pkt_data上交协议栈（如Linux的netif_rx） deliver_packet_to_netstack(pkt_data, pkt_len); // 回收并重置描述符，准备再次接收 desc->BufOffLen = 0; // offset清零 desc->PktFlgLen = EMAC_DSC_FLAG_OWNER; // 仅设置OWNER，其他清0 desc->pNext = NULL; // 将回收的描述符追加到接收队列末尾（需处理EOQ逻辑，类似发送） append_to_rx_queue(desc); } desc = desc->pNext; } write_reg(RX0CP, hw_cp); rx_ctx.sw_processed = hw_cp; write_reg(MACEOIVECTOR, RX_INT_ACK_KEY); }

这个框架省略了错误处理、多通道、分片包处理等细节，但它清晰地展示了描述符队列、中断和缓冲区管理三者如何协同工作。在实际项目中，你需要根据具体的RTOS或内核驱动模型（如Linux Network Driver）来适配这些操作。

最后，我想分享一个在调试千兆以太网吞吐量时得到的深刻教训：不要忽视描述符链表操作和中断处理中的细微延迟。在一次压力测试中，我们发现吞吐量在达到某个阈值后无法提升。使用性能分析工具定位后，发现问题不在数据搬运本身，而是在中断服务程序中，遍历描述符链表并检查状态的那段循环代码。当每秒需要处理数十万个数据包时，这段“简单”的循环开销变得不可忽视。通过将描述符组织成数组并通过索引访问，而不是每次都通过pNext指针进行可能跨Cache行的内存访问，我们显著降低了延迟，最终达到了线速。这个例子告诉我们，在追求极致性能时，硬件机制是基础，但软件实现的细节同样至关重要。理解EMAC/MDIO模块，正是为了能在这些细节上做出正确的设计和优化。