OpenBSD把32位改成64位，10G网卡用户等了太久

2026年3月19日，OpenBSD技术邮件列表里一条补丁帖被标记为"周五提交"。开发者Mike Belopuhov写的这行代码，让等了多年的10G网卡用户终于能松口气。

问题藏在PF队列调度器的带宽字段里——32位整数，上限4Gbps。配置10G带宽时，数字会悄悄回绕，调度行为变得不可预测。就像你告诉水管工要每秒流10升水，他听成了2升，还按2升给你接了管子。

一个字段宽度，卡了高速网络多少年

OpenBSD的HFSC调度器（分层公平服务曲线，一种流量整形算法）用了几十年的32位字段，在千兆时代毫无压力。但10G、25G、100G网卡普及后，这个设计成了天花板。

配置"bandwidth 10G"时，系统内部把10G当成约2.1G处理——32位无符号整数的溢出结果。

更隐蔽的是pftop工具的显示bug：带宽超过4Gbps时，界面上的数字是错的。用户以为自己配对了，实际调度器在瞎跑。这种沉默的失败比崩溃更难排查。

补丁把字段扩到64位，支持到999Gbps。现有低于4G的配置无需改动——兼容性被保留，迁移成本为零。

为什么偏偏是OpenBSD

Linux早在2010年前后就解决了类似问题，FreeBSD的跟进也不算慢。OpenBSD的延迟有其性格：代码审计文化、对"简单正确"的偏执、以及永远人手不足。

核心开发者Stefan Sperling在邮件列表里提过，SMP（对称多处理）解锁和高速网卡驱动是近年优先级更高的战场。队列调度器的带宽字段，属于"能忍就先忍"的技术债。

这种取舍很OpenBSD。安全架构和代码正确性永远排第一，性能优化可以等——等到有人真的被卡住，等到补丁足够干净。

Belopuhov的diff被审了两轮，周五commit。从提交到合并不到一周，在OpenBSD的保守节奏里算快的。

10G用户的真实体感

对跑OpenBSD防火墙的IDC和ISP来说，这个补丁意味着终于可以扔掉 workaround。之前常见的做法是切多个4G以下的子队列，或者干脆不用PF做流量整形。

一位在tech@列表里测试过快照的用户反馈：「queue rootq on em0 bandwidth 10G」现在确实分配了10G，pftop显示也不再跳负数。

这个场景很小众。但OpenBSD的用户群本就垂直——安全设备、边界路由、嵌入式系统。这些场景里，正确的队列调度是刚需，不是锦上添花。

补丁合并当天，OpenBSD Foundation的捐赠页面被转发到几个技术群。有人评论："等了六年，终于可以给10G网卡配10G队列了。"