コンテンツにスキップ

QoS / Buffer の発展トピック

QoS / Buffer / PFC の基本（scheduler、queue map、PG、watermark）を押さえた後は、PFC の運用整合性と buffer pool の設計が次の論点になる。本ページでは、章本文で扱った機能の延長と、他章 (Dual-ToR / 02 BGP / VOQ) との境界を整理する。

ハンドオフ

動的 buffer model の運用詳細

動的 buffer model (buffermgrd が dynamic) では、BUFFER_PROFILE を手書きせず alpha (dynamic threshold) と pool size のみ指定する。alpha は ASIC の SAI_BUFFER_PROFILE_ATTR_SHARED_DYNAMIC_TH に直接マップされ、共有 pool 残量に応じて per-PG/queue の使用上限が自動調整される。alpha = 1/8 を基準に、congestion 多めの ToR では alpha を大きくして burst 吸収を優先し、tail-drop 厳しめの構成では小さくする。

ポートアップ / ダウン時には buffermgrd が BUFFER_PG, BUFFER_QUEUE を再計算し、speed, cable-length の変化を pg_lossless_<speed>_<cable>_profile という profile キーで参照する。pg-headroom 計算式は headroom = 2 * (delay * BW + MTU) ベース。手動上書きは原則しない。

PFC watchdog のチューニング

PFC_WD_TABLE|GLOBAL の POLL_INTERVAL と DETECTION_TIME / RESTORATION_TIME は per-queue 単位で個別に上書き可能 (PFC_WD_TABLE|<port>)。短すぎる detection (100ms) は legitimate な burst を storm と誤検知し、長すぎる (1s 超) と head-of-line block が広がる。fabric 規模が大きいほど、detection を 200ms, restoration を 200ms 程度に揃え、storm 確定後は forward ではなく drop action にして局所封じ込め、を推奨する。

発展トピック

  • Asymmetric PFC: 上流と下流で PFC enable bitmap を非対称に運用するモデル。lossless TC を一方向だけ pause 対象とする使い方で、PORT_QOS_MAP|<port>.pfc_to_queue_map と peer ToR の設定整合が要点。
  • 動的 buffer model: 旧来の static buffer profile から、BUFFER_POOL の thresholds と alpha (dynamic threshold) を ASIC レベルで決める動的モデルへの移行。buffermgrd が BUFFER_PROFILE を auto 計算する。
  • PFC watchdog の per-queue 詳細化: storm 検出窓 / restore 窓を queue ごとにチューニングし、不要な polling load を減らす。PFC_WD_TABLE のパラメータ調整。
  • Tunnel DSCP remap: standby ToR → active ToR の bounce-back を別 PG/queue に逃がす設定。詳細は 05 Dual-ToR と相互参照。
  • Headroom pool: PFC pause 受信中に必要な headroom buffer を共有 pool で確保する設計。port shutdown 時に headroom が解放される動作の理解が必要。
  • WRED / ECN の細分化: green / yellow / red の閾値別ドロップ確率と、ECN-marking 閾値を queue ごとに調整。CSE 系 telemetry と組み合わせて congestion 兆候を捕捉する。
  • Watermark の align-with-port-config: port admin down 時に watermark を 0 に clear する整合性改善で、運用 dashboard の誤検知を減らす。

既知の制約と回避方法

  • buffer profile の手書きと auto 計算の混在: 一部 SKU で pg_lossless_*_profile.json を手書き、別 SKU で動的計算を使うと、deployment yaml が SKU ごとに分岐する。SKU 単位で auto / manual を統一する。
  • PFC storm 中の watermark 異常値: storm で queue depth が暴れると watermark API の peak が過大になる。sonic-clear queue watermark を保守時に発行して baseline を取り直す。
  • scheduler weight と shaper の同時設定: SCHEDULER の weight と pir/cir を両方設定すると ASIC によって解釈が違う。WFQ + shaping の組合せは platform docs と SAI sample で必ず確認する。
  • ECN-only deployment: PFC を無効にして ECN だけで lossless を狙う構成は、congestion 検出が遅れて queue が膨らむと drop に至る。host TCP stack の DCTCP 設定とセットで運用する。

将来計画 / ロードマップ

  • align-watermark-flow-with-port-configuration HLD が port lifecycle と watermark の整合を扱い、これを起点に counter の reset 周りが整理される方向。
  • Dynamic buffer model の telemetry 統合が長期テーマで、buffer pool の utilization を OpenConfig schema で export する話が継続。
  • SAI 側で SAI_BUFFER_POOL_ATTR_XOFF_SIZE や per-queue headroom counter の attribute が拡張されており、SONiC 側 schema 追随が見込まれる。

関連 RFC / 仕様書

upstream 開発の最新動向

  • sonic-buildimage 配下の buffermgrd で動的 buffer model のチューニング PR が継続。alpha 値の自動計算ロジックが SKU 別に分岐していくため、platform 依存が増える傾向。
  • sonic-swss の qosorch で WRED profile attribute 更新と PFC watchdog の storm detection 改善 PR が定期的に入る。
  • Streaming telemetry 側 (10 gNMI) で COUNTERS_DB の watermark / queue / PG 数値を export する設定例が拡張中。

トラブルシュート観点

  • lossless TC で drop が出る場合、(1) BUFFER_PG の headroom が不足、(2) PFC watchdog の forward action で storm を素通りさせている、(3) peer 側で PFC を送出していない、の 3 つを順に切り分ける。show pfc counters で peer から PFC frame を受信しているかを確認。
  • buffer pool exhaust は sonic-clear watermark queue + sonic-clear watermark pg で baseline を取り直し、show buffer pool の XOFF used を観察する。
  • WRED が機能しない場合、SCHEDULER の type が WRR/DWRR であり、queue に WRED profile が bind されていることを QUEUE table で確認する。WRED_PROFILE の ecn 設定 (ecn_all, ecn_none) も要点。

検証パスとラボ要件

  • PFC end-to-end の検証は sonic-mgmt の qos/test_qos_sai.py で行う。SAI 側 attribute と Redis 設定の整合確認が含まれる。
  • 動的 buffer model の alpha チューニングは、合成 burst (microburst injector) を流して BUFFER_POOL_WATERMARK_STAT_COUNTER の peak を観察する手順が標準。

関連ページ (追補)

関連ページ