OpenBSD：PF 佇列突破 4 Gbps 瓶頸 （★ 101 分）
OpenBSD 的 PF（Packet Filter，封包過濾/防火牆）長期支援用 HFSC（Hierarchical Fair Service Curve，階層式公平服務曲線）在 pf.conf(5) 以 queue 規則做流量整形與頻寬分配。但 HFSC 的服務曲線結構 struct hfsc_sc 內部以 32 位元欄位儲存頻寬，導致可設定的值會被悄悄上限在約 4.29 Gbps（u_int 的最大值）。在 10G、25G、100G 網路介面愈來愈常見、OpenBSD 核心也在解鎖 SMP（Symmetric Multi-Processing，對稱多處理/多核心）效能的背景下，這個限制開始造成困擾：把 queue 設成 bandwidth 10G 會發生數值溢位回繞，排程行為變得不正確且難以預測。
最新補丁把核心 HFSC 排程器的頻寬欄位從 32 位元擴成 64 位元，直接移除 4 Gbps 瓶頸，同時修正 pftop(1)（PF 即時狀態工具）在顯示超過 4 Gbps 時數值錯亂的舊問題。對使用者而言，原本的設定語法不變，但在高速介面上設定頻寬終於會如預期生效；系統宣稱可接受到 999 G 的設定值，既有低於 4 G 的規則也無須修改。編輯也指出 openbsd-tech 郵件清單的討論已認為程式碼接近可提交，並呼籲測試 -current 版本與捐款給 OpenBSD Foundation。
Hacker News 討論裡，不少人先把焦點放在「999G」這個上限：有人質疑為何不是 1024G 這類更直覺的界線，也有人翻補丁說明指出實作上大約可到 ~1 Tbps（約 1 兆 bit/s），限制可能源自內部換算在 2^40 以上會溢位的保護措施。也有留言提醒別太早喊「夠用到未來」：IEEE 802.3dj（Terabit Ethernet 規格草案）正朝 1.6T/1600G 前進，800G 的 NIC（Network Interface Card，網路介面卡）也已出現，若再用 LACP/LAGG（Link Aggregation，鏈路聚合）做 bond（介面綁定）就可能達到 1600G；因此有人拿「640K 記憶體永遠夠用」的典故嘲諷「永遠夠用」的措辭。另有人認為 Ethernet 這個名字本身就代表「從 OSI 模型（Open Systems Interconnection，網路分層模型）較上層看起來仍像 Ethernet、且遵循廣泛標準」的承諾，所以短期內不太可能被取代。
更多工程面討論則回到「在多 Gbps 甚至 Tbps 時代，還該不該在核心內做逐封包整形」：有人主張高吞吐場景常見作法是把資料平面（data plane）移到使用者空間，採 DPDK（Data Plane Development Kit）、netmap 或 XDP（eXpress Data Path）等方式批次處理封包並用 DMA（Direct Memory Access，直接記憶體存取）直通網卡，核心較像控制平面（control plane）；PF/ALTQ（ALTernate Queueing，OpenBSD 的佇列/整形架構）屬傳統核心內模型，較早碰到效能天花板。也有人澄清本文修的是「頻寬限制的數值表示」而非 PF 的實際過濾速度，並指出在 10G+ 環境下做嚴格流量整形本來就偏小眾，且許多 queue 的限速往往低於 4 G；同時也有人批評「靜默回繞」比起直接報錯更危險。關於部署面，留言者普遍認為 OpenBSD 傳統上更重視安全與可維護性，雖然近年像 BGP（Border Gateway Protocol，邊界閘道協定）等效能有所進步，但仍有人提到 PF 偏單執行緒、FreeBSD 的 PF 與高階光纖/光模組支援更成熟（如 DOM，Digital Optical Monitoring，光功率監測；SFP/QSFP，小型可熱插拔光模組介面/四通道版本），使 OpenBSD 在資料中心情境較不吃香。
👥 26 則討論、評論 💬
https://news.ycombinator.com/item?id=47439320