Linux网络设备驱动这个标签在不少内核开发者眼里属于看起来就头大的那一类。它不像字符设备驱动那样简单直白打开、读写、关闭就完事也不像块设备驱动那样有明确的数据块语义。网卡驱动要面对的是碎片化的小包、高并发的收发、硬件中断的狂轰滥炸以及和协议栈之间复杂的配合。我当年第一次把网卡驱动跑通时最深的感受是驱动本身只是搬运工但搬运工要懂物流园的整套流程。这个专题讲的就是这套流程从设备注册、DMA描述符、NAPI轮询到中断处理、多队列分发、性能调优几乎覆盖了内核里最讲究效率的那部分代码。这篇文章适合谁看如果你正准备从字符设备驱动往网络子系统走或者你在嵌入式平台上遇到过网卡能link up但收不到包这种诡异问题再或者你明明开了多队列但中断总是打在一个CPU上那么这篇内容能帮你把这些碎片拼起来。网络上有很多零零散散的博客讲某个驱动文件但这个专题的价值在于串起来硬件、DMA、中断、协议栈、性能工具缺一不可。1. 这个专题到底在解决什么问题网卡驱动只是包搬运工吗在网络设备驱动的语境里我们需要先弄清楚一个基本事实驱动并不负责解析IP头、TCP端口这些东西协议解析全部交给内核协议栈。驱动要做的是把线缆上传进来的数据帧通过硬件和DMA搬到内存中再包装成内核sk_buff结构送给协议栈发送方向则反过来把已经封装好的skb拆出物理地址交给硬件去发送。听起来简单但难点在效率和异步。网卡驱动和字符设备驱动最大的区别在于数据到达的不可预知性。你永远不知道下一秒会进来多少包可能一个包都没有也可能瞬间涌入几百万个小包。如果你靠中断一个一个通知CPU那么在高PPS场景下CPU会被中断淹没整个系统都在切换上下文和压栈出栈用户态程序反而饿死。所以驱动设计很早就从每次中断处理所有包演进到中断先唤醒、轮询再扫尾的NAPI模式再往后是队列多到可以绑核以及把部分处理下沉到XDP。这个专题真正解决的是三个层面的问题第一让驱动能正确地把帧送进协议栈这涉及寄存器初始化、DMA、内存同步第二让驱动在高负载下不丢包不崩溃这涉及NAPI预算、队列深度、中断合并的权衡第三让驱动能利用上多核硬件这就是RSS、XPS、中断亲和性这些机制存在的意义。很多新手把能ping通当成驱动开发完成的标准实际上那只是万里长征第一步。一台只有100Mbps能力的业务服务器和一台千万PPS的转发盒子两个场景下同一份驱动代码要调的参数完全不同。1.1 网卡驱动在内核网络栈中的位置如果画一条数据路径物理帧从网线到网卡的MAC/PHY经过内部FIFO或者直接由DMA引擎搬到内存中的描述符缓冲区触发中断或者置位状态寄存器然后驱动在软中断上下文通过NAPI拿到这批缓冲区把数据转成skb调用napi_gro_receive之后就走进了协议栈的“上层”世界。也就是说驱动是硬件和协议栈之间的适配层它管理的是DMA描述符、控制寄存器、中断状态、统计计数器而不是TCP拥塞窗口之类的东西。这也意味着你要同时理解两类接口。向下是硬件手册定义了你这个网卡的寄存器布局、DMA描述符格式、中断状态位向上是内核网络子系统的API比如net_device_ops、NAPI结构、skb生命周期。很多驱动代码看起来难读就是因为你必须在这两个世界的边界上来回切换思维。比如硬件手册说接收描述符的bit 31表示该描述符已被硬件写入数据到了内核侧则变成这个内存地址对应的是一个struct skb要么交给napi_gro_receive要么回收重新映射。1.2 驱动思维误区不是读完寄存器就完事我见过不少从单片机裸机编程转过来的开发者他们习惯性地认为配置完寄存器、初始化完DMA地址数据通路就通了。但在Linux网络驱动里你还要处理几个很要命的问题缓存一致性、内存屏障、NUMA亲和性。比如DMA写过的内存CPU读之前要不要做cache invalidate不同的总线架构和行为并不完全一致dma_map_single和dma_unmap_single的配对使用必须严格。又比如描述符环上的状态位硬件写、CPU读中间要不要加dma_rmb()乱序访问会导致你看到半新的描述符进而解析出错误的长度字段。所以这个专题要讲的不只是照着手册配寄存器而是建立一套硬件异步、内核调度、内存同步的整体观。先把模型搭起来再谈怎么优化。2. 驱动骨架从分配net_device到数据通路上线写一个网络设备驱动骨架并不复杂但每一环都有讲究。核心对象是struct net_device它是内核网络子系统中代表一个网络设备的实体。你要做的第一步通常是在驱动的probe函数里分配这个结构设置好名字、特性、netdev_ops然后注册到内核。分配方式一般用alloc_etherdev(sizeof(struct my_priv))一个函数两件事都干了既分配了struct net_device本身又额外分配了一块私有数据区私有时数据通过netdev_priv(dev)来获取。这个设计非常方便你不需要维护一个全局的驱动状态指针设备生命周期和私有数据一起走。2.1 必备结构netdev_ops和ethtool_opsnetdev_ops是你实现设备操作的主战场。以最简单的情况为例static const struct net_device_ops my_netdev_ops { .ndo_open my_open, .ndo_stop my_stop, .ndo_start_xmit my_start_xmit, .ndo_get_stats64 my_get_stats64, .ndo_change_mtu my_change_mtu, };打开设备时内核通过ndo_open让你做初始化关闭时通过ndo_stop清场要发包时调用ndo_start_xmit。很多人会忽略ndo_get_stats64但在排查丢包时它极其有用驱动里维护的rx_missed、tx_dropped这些统计最后都靠这个回调上报给ip -s link和ethtool -S。ethtool_ops则是给用户态工具ethtool提供信息通道的比如驱动程序名、支持的速率、ring参数、队列数、网卡卸载特性。调试的时候ethtool -S能看到驱动私有的统计项这些往往比内核通用统计更能定位问题。很多厂商驱动会把硬件错误、FIFO溢出、描述符环重试次数都放在这里。2.2 注册流程从总线探测到设备上线以PCI网卡为例流程大致是module_init里调用pci_register_driver当内核发现匹配的PCI设备就会进入你的probe函数。在probe里你要做几件关键的事pci_enable_devicepci_set_master使能总线主控能力因为DMA需要设备主动发起总线事务然后pci_request_regions申请BAR资源接着pci_set_dma_mask和pci_set_consistent_dma_mask设置DMA地址宽度。这里有一个容易踩的坑如果设备支持64位DMA但你的驱动没设置内核默认可能只给32位地址范围在高位内存分配DMA缓冲区会失败或回退轻则性能低重则直接分配失败。DMA掩码不是“尽量设高”而是要按硬件手册的“最大寻址宽度”来设。拿到基地址后你要ioremap寄存器空间解析中断。然后执行alloc_etherdev、填充网卡特性、注册netdev_ops、netif_napi_add最后register_netdev(dev)。注册成功之后设备就会在内核里出现凭借ip link set eth0 up就可以触发你的ndo_open。这个顺序必须在probe里严格执行尤其不能register_netdev之后再netif_napi_add因为你不知道用户什么时候就会立刻执行up竞态一旦发生NAPI没注册好就开始收包系统可能直接panic。2.3 ndo_open和ndo_stop生命周期的上下电ndo_open是数据通路真正启动的地方。通常要做分配DMA接收环和发送环申请中断request_irq或者启用MSI-X初始化NAPI使能napi_enable然后通过硬件寄存器启动DMA引擎最后netif_start_queue和netif_carrier_on。ndo_stop的顺序则完全相反先netif_carrier_off、netif_stop_queue再关硬件DMA、关中断、销毁NAPInapi_disable、释放DMA环。顺序不能乱否则可能出现停掉中断后硬件还在往内存写数据然后你把缓冲区释放了硬件DMA写进已经被释放的内存轻则数据损坏重则导致内核崩溃。我见过一种很典型的bugndo_stop里先释放了RX缓冲区然后再去停硬件DMA引擎。驱动在卸载测试时倒也没什么异常一旦收到持续流量dmesg里就报各种use-after-free相关错误。排查了好久才发现是顺序问题不是并发问题。硬件异步这件事必须时刻当回事。3. 数据收发的核心DMA、环形缓冲区与NAPI设备驱动的核心数据通路不是函数调用而是内存里的一组环形缓冲区。收方向的逻辑是驱动预先分配一批缓冲区把物理地址一段段填进描述符环硬件收到数据后通过DMA把帧写入这些缓冲区然后更新描述符状态和硬件写指针驱动发现新数据后取走缓冲区再补上空缓冲区。发方向则是驱动把待发送的skb数据DMA映射交给硬件硬件发送完成后更新完成状态。环形缓冲区之所以叫“环”是因为它本质上是一个头和尾围起来的数组硬件和软件各自维护一个索引当索引到数组末尾时回到0。为了让取模运算更高效数组大小几乎总是2的幂这样idx (ring_size - 1)就替代了idx % ring_size。3.1 RX描述符环的设计与缓冲区管理接收环的每个描述符通常包含一个缓冲区地址、一个长度字段、一个状态字段。驱动在初始化时分配好这些描述符内存并且用dma_alloc_coherent分配一致内存保证CPU和硬件看到的是同一份缓存视图。对于每个描述符再从内核分配一个data buffer用dma_map_single把物理地址映射到描述符里。这里要注意方向参数。RX方向是设备写内存、CPU读内存map方向是DMA_FROM_DEVICETX方向是CPU写内存、设备读内存map方向是DMA_TO_DEVICE。如果方向写反在某些架构上虽然不报错但会产生cache一致性隐患表现是时好时坏极其难查。RX缓冲区大小怎么定如果网卡支持的最大MTU是1500你得考虑以太网头、CRC、可能还有VLAN tag所以常见做法是分配mtu 以太网头 预留头部 VLAN 一些对齐这么大的缓冲区。有些驱动直接分配2KB甚至4KB反正内核页面也支持。缓冲区分配是收包路径上的高频操作性能敏感所以现代驱动普遍引入page_pool来管理页面池避免每次收包都走一遍页面分配器。3.2 DMA映射和同步的细节DMA映射分为两类一致性和流式。描述符环本身用一致性映射发完就不用操心缓存同步而每个skb的data buffer属于流式映射需要dma_map_single/dma_unmap_single在每次收发时配对。很多驱动为了性能在TX完成中断或者poll中统一做dma_unmap_single这要求你记录每个skb的DMA地址和长度放在一个软件描述符数组里按顺序对应环形缓冲区里的槽位。踩坑经验dma_map_single之后在硬件还没有完成写操作之前不要碰那段内存。有些调试加日志的开发者喜欢把skb data里的内容打印出来看看这在TX方向还没问题但在RX方向一旦你从CPU读了而DMA引擎同时也在写就会产生cache coherence的undefined behavior。实测表现就是偶发收到CRC错误或者数据错位。3.3 NAPI从一包一中断到积攒一批NAPI的引入是为了解决高PPS下中断风暴问题。老式驱动是来一个包产生一次中断CPU大量时间耗在中断上下文。NAPI的思路是第一个包还是中断通知中断handler里把该网卡的中断关了然后调用napi_schedule把NAPI结构挂到当前CPU的softnet等待队列上。随后内核在软中断上下文调用你的poll函数你在poll里收尽可能多的包一直收到预算budget或者队列空了为止。收完之后重新开启中断。poll函数的返回值含义是我实际收了多少包。如果你收了budget个但环里还有数据那么内核会把你继续排在处理队列里下一轮马上再调用poll如果你没达到budget就收空了就应该调用napi_complete_done并重新开启中断。这里的平衡是budget设大了一次收包耗CPU太多其他任务延迟高设小了中断关闭时间短NAPI很快结束又可能频繁进中断。所以内核里用netdev_budget、netdev_budget_usecs这类参数做全局控制你可以通过调整来改变CPU占用和延迟的取舍。NAPI还和GRO泛接收卸载配合紧密。napi_gro_receive里如果协议栈发现多个包是同一条连接的可以合并成更大的段再交给上层显著减少上层处理次数。这一层不需要硬件参与纯软件所以驱动即使不支持硬件GRO也能通过设置NETIF_F_GRO享受到部分收益。3.4 发送路径的几个关键点ndo_start_xmit是驱动发送的入口。内核传给你一个skb你的职责是把这个skb交给硬件。关键问题是发送队列满的时候怎么办。你的驱动通过netif_stop_queue告诉内核发送队列已满不要再往下了等有描述符被硬件释放出来再netif_wake_queue唤醒队列。这里有个经典问题ndo_start_xmit在发送完成后返回NETDEV_TX_OK但这个返回值只代表你接受了这个skb不代表硬件已经把数据发到线上了。真正确认发送完成的时机是后续的TX完成中断或者poll中硬件报告传输完成。此时驱动调用dev_kfree_skb_any释放skb并更新统计。某些性能调优场景还要在TX完成时再检查一下发送队列是否能唤醒避免出现队列空着但netif_queue_stopped位一直为1导致发包卡死的情况。4. 中断与下半部为什么驱动不能只活在中断里网络驱动的处理路径分两段。第一段是硬中断上下文要求短小精悍因为硬中断会打断CPU上正在跑的进程第二段是软中断上下文这才是数据包处理的真正主战场。理解这两段的关系对排查为什么CPU%软中断很高或者为什么高频下丢包非常关键。4.1 硬中断handler里该做什么一个成熟的网卡驱动硬中断handler通常只做四件事读取中断状态寄存器清掉中断挂起位保存需要处理的队列信息如果有可用数据或发送完成事件就把对应的NAPI结构调度出去。不要把任何实际收包逻辑放在hardirq里也不要在hardirq里拿锁做复杂的清理。硬中断里待得越久其他中断的延迟就越高。如果你开启了MSI-X和每个队列一个中断向量那么每个中断handler只需要关心自己的队列。这也是多队列网卡性能好的关键。传统PCI INTx共享中断是所有设备共享一条线一个中断来了不能只认定是自己的还要读状态位挨个判断这种模式在现代高性能网卡上已经基本被丢弃。4.2 软中断net_rx_action和ksoftirqd内核在硬中断handler里调用napi_schedule之后实际上是把NAPI结构挂到了当前CPU的softnet_data的poll_list上然后设置NET_RX_SOFTIRQ软中断标志。软中断处理流程net_rx_action会遍历poll_list逐个调用驱动的poll函数。软中断不能休眠、不能阻塞驱动代码里所有路径都得是非睡眠的。当软中断积压过多内核会把剩余的软中断处理推迟到ksoftirqd内核线程中执行。/proc/net/softnet_stat可以看出来以前经常有人只看dropped列其实time_squeeze列也很重要它表示CPU的softnet backlog在预算内没处理完被强制挤出的次数。如果这个数在暴涨说明你的包处理能力已经顶到天花板了。4.3 中断合并与低延迟的取舍中断合并coalescing是现代网卡一个重要的调优点。硬件支持这样一种模式不每收到一个包就立刻产生中断而是攒一小段时间或者攒一定数量的包再统一上报中断。这样能大幅降低中断频率、提升吞吐。但副作用是单包延迟变高因为包到了之后可能要在硬件里等一会儿才通知CPU。ethtool -c能看到当前合并参数ethtool -C eth0 rx-usecs 8这类命令可以调整。适合高吞吐转发的场景可以调大合并时间适合低频小包交互的场景比如游戏服务器就要调小甚至关闭合并。我做延迟敏感项目时通常先把rx-usecs设成0确认延迟正常再一点点增大观察PPS和CPU开销曲线找到一个平衡点。不要照搬别人的数值每个网卡和外场流量模型差别极大。5. 多队列与流分发从单线程收包到充分利用多核早期网卡只有一个DMA环所有包都进同一个队列中断也只打在同一个CPU上。哪怕机器有32个核收包路径只有单核在跑性能上限一目了然。后来出现的多队列设计目的是让多个CPU核并行处理网络包。每个队列拥有独立的DMA描述符环、独立的NAPI实例、独立的中断。5.1 有多少个队列怎么分配中断你可以在ethtool -l eth0看到网卡当前能启用几个队列ethtool -L eth0 combined 8可以调整队列数。这里的combined是指RX/TX对称且共用一个队列组的模式。如果网卡支持内核为每个队列申请一个MSI-X中断向量。中断绑定也很有讲究。/proc/interrupts里你能看到每个中断号在每个CPU上的累计次数。如果所有中断都打在一个CPU上另一个核闲着那就是没做中断亲和。通常可以把不同队列的中断分担到不同的CPU核或NUMA节点上工具上可以用irqbalance自动做或手动写/proc/irq/N/smp_affinity。有的驱动还提供set_irq_affinity_hint。5.2 RSS和流哈希让同一条流待在同一个队列多队列带来一个新的问题同一个TCP连接的双向包如果被哈希到不同的队列、不同的CPU那么报文乱序就会明显增加TCP看到乱序就得重传性能不升反降。RSSReceive Side Scaling就是硬件在接收时对四元组做哈希然后根据哈希结果选择队列这样同一条流几乎总进同一个队列。哈希算法和key一般由硬件维护驱动侧只要把这个特性打开即可。通过ethtool -k eth0查看ntuple和rxfh-indir这类参数。注意如果你的网卡只有2个队列但哈希表把60%的流打到了队列1那就不均衡了。可以用ethtool -X eth0 equal 2把indirection table重置成均匀分布。5.3 XPS发送队列也要选核很多人只关心接收侧多队列忘记发送侧同样需要亲和。XPSTransmit Packet Steering是内核里的一个机制它允许你把某个发送队列绑定到一组CPU核上。当CPU要发送这个skb时内核会尝试选择绑定在该CPU的发送队列这样可以减少锁竞争、提升cache命中率。查看/sys/class/net/eth0/queues/tx-0/xps_cpus里面是一个CPU掩码。手动设置时比如你想让TX队列0只由CPU0和CPU1使用就写入3二进制0b11。配合RSS的接收亲和能做到同一条流的接收和发送都落在同一批CPU上性能提升在一些高并发小包场景下非常明显。6. 驱动调优与故障排查网卡不干活、疯狂丢包怎么办网卡驱动的问题不像用户态程序那么好调试一旦数据通路出错表现可能是完全不收包、间歇性丢包、大量CRC错误、或者CPU软中断飙高。要高效排查先学会看几个关键命令和文件。6.1 先看接口统计ethtool -S说了什么ip -s link show eth0只能看到很笼统的rx/tx packets和errors。真正的金矿在ethtool -S eth0里厂商驱动会暴露非常细的计数器比如rx_missed、rx_dropped、rx_fifo_errors、tx_aborted_errors。不同的计数器含义不同要多看驱动文档。实战案例是这样的某高速采集项目X流量一上来用户报告网络每秒丢几千个包。我首先跑ethtool -S发现rx_missed疯狂增长而rx_dropped为0。这表示硬件FIFO或者描述符环已经来不及处理数据在到达DMA引擎之前就被丢了。随后ethtool -g eth0看当前ring size默认只有256个描述符流量突发一上来深度不够硬件只能丢弃新包。我把RX ring size调到4096重测之后rx_missed基本归零。排查这类问题不要先猜协议栈先用计数器的位置定位丢包发生在哪一级。6.2 中断分布和软中断瓶颈的排查如果某个CPU的si软中断占用长期超过80%而其他CPU空闲那就是典型的收包集中在一个核上。排查顺序先看/proc/interrupts确认每个网卡队列中断分布再看/proc/net/softnet_stat的第11列左右确认dropped和squeeze情况最后检查irqbalance是否生效。如果多队列中断分布正常但单个核的软中断还是过高可以考虑把netdev_budget调低让单次poll不要消耗过多时间同时考虑用ethtool -L增加队列数让更多核参与。还有一个容易忽略的点确认irq affinity是否和CPU的NUMA节点匹配。跨NUMA访问DMA缓冲区会有额外的内存延迟高PPS下差距能到百分之二三十。6.3 小包性能瓶颈pps比带宽更致命网卡标称万兆指的是线速10Gbps但如果全是64字节小包线速就是约1488万pps。驱动处理每个包有固定开销包括中断/NAPI、DMA unmap、skb分配、协议栈处理这个小包场景最容易暴露瓶颈。如果你测到吞吐只有几十万pps先别急着怪驱动考虑是不是CPU频率太低、锁竞争太严重或者分配器成了热点。优化方向一般有几个使用page_pool或驱动内部buffer recycled减少skb数据区分配次数开启GRO减少上层报文合并成本开启RSS和XPS让多核分摊对于支持XDP的网卡可以直接在驱动层做ndo_xdp_xmit绕过skb和协议栈适合纯转发场景。注意不是所有驱动都支持这些特性很多时候买卡之前就得想清楚性能目标。7. 实操过程中的踩坑记录与快速查验清单我在这个专题上踩过的坑比成功经验更值得写下来。这些坑不一定在文档里写得明白但几乎每个人迟早都会遇到。7.1 五个高频坑第一RX缓冲区要预留足够的headroom。内核协议栈经常需要在数据包前面加各种头比如VLAN、隧道封装如果skb的headroom不够就只能线性拷贝白白浪费性能。用netdev_alloc_skb时不要裁得太小至少保留NET_SKB_PAD字节。第二DMA映射和unmap必须严格配对。如果TX完成处理里漏了unmap长时间运行会泄漏DMA映射条目IOMMU开启时直接报错IOMMU关闭时内存地址越积越多最终导致设备无法分配新的映射。这种问题不会立刻爆发往往在持续运行几小时后才出现排查起来特别头疼。第三NAPI的poll里不能睡眠不能调用msleep不能拿会导致睡眠的锁。看起来很简单但很多人在poll里做register访问时用了带sleep的锁一旦高频中断打入驱动就像神经病一样时好时坏dmesg还时不时报BUG: sleeping function called from invalid context。第四TX超时处理。内核每隔一段时间会检查发送队列是否卡住如果ndo_start_xmit一直NETDEV_TX_BUSY或者硬件发送完成中断丢失你会看到NETDEV WATCHDOG: eth0 (my_driver): transmit queue 0 timed out。这时候驱动要能复位该队列甚至整个设备重置信否则只能卸载重载。调试时先检查TX完成中断是否正常触发再检查netif_stop_queue是不是一直没苏醒。第五卸载时的同步问题。ndo_stop不能只关中断还要确保中断handler和NAPI不会再次被调度否则会出现设备已移除但中断还在跑的情况。一般流程是napi_disable、free_irq顺序别弄反。7.2 快速查验清单现场症状先查什么常用手段网卡link up但收不到包驱动统计里的RX计数是否增长ethtool -Sdmesgrx_missed暴涨接收环深度不足ethtool -G调大ring size单个CPU软中断100%中断是否绑核不均/proc/interruptsirqbalance手动affinitytx_timeout频繁触发发送队列是否卡死ethtool -S查看tx停顿dmesg watchdog高PPS下大量rx_dropped中断合并过紧或NAPI预算不足ethtool -C调整netdev_budget丢包但所有计数器都不涨可能是上层socket接收队列满ss -lnt检查应用接收模式7.3 往更深处走XDP和可编程网络驱动专题的下一站往往是XDP和可编程包处理。XDP允许你在驱动收到的原始帧上、甚至在skb生成之前就执行一段BPF程序。这意味着驱动可以决定这个包直接丢掉转发到另一个网卡或者把它放到用户态完全绕开协议栈性能能提升几倍到一个量级。现代主流网卡驱动都实现了ndo_xdp_xmit和相关钩子有条件的话这个方向是网络驱动开发最有前景的延伸。页池、内存回收、零拷贝、TCP分段卸载又是另一片深水区。但不管是哪一步底层这套描述符、DMA、NAPI、中断、队列的思维模型都是通用的掌握了它换任何网卡、任何驱动框架你都能很快上手。按照我个人经验真正写好一个网络设备驱动不是把寄存器的每一个bit都背下来而是搞清楚数据在硬件缓冲区、DMA描述符、内核skb之间的流动方式和节奏。测一万次ping通不如认真看一次ethtool -S里的异常计数器增长。遇到问题先分级定位不要拿着工具乱扫。这个思路不仅适用于网卡驱动也适用于职业生涯里各种底层系统问题。