web-dev-qa-db-ja.com

NAPIと適応割り込み

次の2つのテクノロジを使用して、ネットワーク負荷が高い場合の割り込みオーバーヘッドを軽減する方法を誰かに説明してもらえますか?

  1. Adaptive-rx/Adaptive-tx、および
  2. NAPI;

Linuxカーネルソースレベルに近い違いを説明する回答をいただければ幸いです。また、NICを強制して、400Mbps程度の負荷で合体モードをポーリング/中断するように強制する方法を聞きたいと思います。

その他の背景:

問題は、bnx2およびe1000ドライバーが「ethtool -C Adaptive-rx on」コマンドを無視することです。これはおそらく、それらのドライバーが適応割り込みをサポートしていないためです。 Broadcom Programmerのリファレンスマニュアルには、この機能はBCM5709でサポートされる必要があると記載されていますが、NICハードウェア。

したがって、NAPIを試し、netif_napi_add()関数呼び出しで重みを64から16に減らして、はるかに低い負荷でポーリングモードでNICを強制する)ことを決定しましたが、残念ながらうまくいきませんでした。 NAPIはNICで特別なハードウェアサポートを必要としないということですが、それは正しいですか。

私が使用しているハードウェアはBCM5709 NIC(bnx2ドライバーを使用)です。OSはUbuntu 10.04です。CPUはXEON 5620です。

12
user389238

割り込み調整の背後にある主な原則は、受信フレームごとに1つ未満の割り込み(または送信フレーム完了ごとに1つの割り込み)を生成し、割り込みを処理するときに発生するOSオーバーヘッドを削減することです。 BCM5709コントローラは、ハードウェアで割り込みを結合するためのいくつかの方法をサポートします。

  • Xフレーム(ethtoolのrx-frames)の受信後に割り込みを生成します
  • X usecs(ethtoolのrx-usecs)の後にフレームが受信されなくなったときに割り込みを生成する

これらのハードウェアメソッドを使用する場合の問題は、スループットまたは遅延を最適化するためにそれらを選択する必要があることです。両方を使用することはできません。受信フレームごとに1つの割り込み(rx-frames = 1)を生成すると、レイテンシは最小限に抑えられますが、割り込みサービスのオーバーヘッドの点で高コストになります。大きな値(たとえば、rx-frames = 10)を設定すると、受信した10フレームごとに割り込みを1つだけ生成することで消費されるCPUサイクルの数が減りますが、その10グループの最初のフレームのレイテンシが高くなります。

NAPI実装は、トラフィックが束になるという事実を活用しようとするため、受信した最初のフレームですぐに割り込みを生成し、すぐにポーリングモードに切り替えます(つまり、割り込みを無効にします)。いくつかのフレーム(質問では16または64)または時間間隔をポーリングした後、ドライバーは割り込みを再度有効にしてやり直します。

予測可能なワークロードがある場合は、適切なトレードオフを提供する上記のいずれか(NAPI、rx-frames、rx-usecs)に固定値を選択できますが、ほとんどのワークロードは変化し、最終的にいくつかの犠牲を払うことになります。ここで、adaptive-rx/adaptive-txが役立ちます。ドライバーは常にワークロード(1秒あたりの受信フレーム数、フレームサイズなど)を監視し、ハードウェア割り込み合体スキームを調整して、トラフィックの少ない状況での待機時間を最適化するか、トラフィックの多い状況でのスループットを最適化するという考えがあります。それはクールな理論ですが、実際に実装するのは難しいかもしれません。少数のドライバーだけがそれを実装し( http://fxr.watson.org/fxr/search?v=linux-2.6&string=use_adaptive_rx_coalesce を参照)、bnx2/e1000ドライバーはそのリストにありません。

各ethtool合体フィールドがどのように機能するかの説明については、次のアドレスにあるethtool_coalesce構造の定義を参照してください。

http://fxr.watson.org/fxr/source/include/linux/ethtool.h?v=linux-2.6#L111

特定の状況(〜400Mb/sスループット)では、rx-framesとrx-usecsの値を調整して、ワークロードに最適な設定にすることをお勧めします。 ISRのオーバーヘッドと、アプリケーションの遅延(httpd?など)の感度の両方を確認します。

デイブ

18
Dave