OpenBSD的PF防火墙包过滤器近期突破了HFSC流量整形队列的4Gbps带宽限制，解决了之前因32位结构体导致的10G/25G/100G高速网络接口配置问题。这一改进为现代高速网络环境提供了更好的支持。

标题：PF队列突破4Gbps带宽限制

主要内容： OpenBSD的PF数据包过滤器长期支持通过pf.conf中的queue规则实现HFSC流量整形。但由于HFSC服务曲线结构（struct hfsc_sc）存在32位限制，带宽值被静默限制在约4.29Gbps（即u_int类型的最大值）。

随着10G/25G/100G网络接口普及，以及OpenBSD开发者在内核SMP支持和高速网卡驱动方面的进展，这一限制开始显现弊端。当配置bandwidth 10G时会出现数值回绕，导致调度行为异常。

最新补丁将内核HFSC调度器的带宽字段从32位扩展至64位整数，彻底解决了这一瓶颈。该补丁还修复了pftop中4Gbps以上带宽值显示错误的问题。

实际影响： - 现在可以正确配置现代高速接口的PF队列带宽 - 支持最高999G的带宽配置（示例配置见原文代码块） - 现有低于4G的配置无需修改仍可正常工作

开发动态： - 补丁已在技术邮件列表讨论并通过审核 - 计划于2026年3月20日提交代码 - 鼓励用户测试-current快照并向OpenBSD基金会捐款

（注：删减了网站导航、相关文章列表、版权声明等非核心内容，保留了技术细节和更新要点）

以下是评论内容的总结：

支持现有上限的观点
- 认为999G的数值上限足够应对当前和未来的需求
"Values up to 999G are supported, more than enough for interfaces today and the future."
引用比尔·盖茨640K内存的典故暗示需求预测的局限性

对性能上限的质疑
- 质疑PF能否在4Gbps以上速度进行流量整形
"Can pf actually shape at speeds above 4 gbps?"
- 指出当前消费级硬件已普遍配备2.5G端口，认为上限设置过低
"even cheap consumer hardware ships with 2.5G ports, this number seems weirdly low"
质疑OpenBSD在数据中心等高速场景的应用现状

技术架构差异
- 指出OpenBSD的PF仍是单线程架构，而FreeBSD已实现多线程
"It’s still single threaded. PF in FreeBSD is multithreaded."
建议家庭网络用OpenBSD，其他场景用FreeBSD

实际需求讨论
- 用户表示现有2Gbps带宽已完全够用，对4Gbps需求感到困惑
"I have 2 Gbps and that's more than enough already"
"not even sure what to use it for lol"

总结呈现了技术适用性、性能质疑、架构对比和实际需求四个维度的讨论，保持正反观点平衡，引用关键语句并保留中英文对照。