割り込みモデレーションの背後にある主な原則は、受信フレームごとに1つ未満の割り込み（または送信フレーム完了ごとに1つの割り込み）を生成し、割り込みを処理するときに発生するOSオーバーヘッドを削減することです。BCM5709コントローラーは、割り込みを合体させるためにハードウェアでいくつかの方法をサポートしています。
- Xフレーム（ethtoolのrxフレーム）を受信した後に割り込みを生成します
- X usecs（ethtoolのrx-usecs）の後にフレームが受信されなくなったときに割り込みを生成する
これらのハードウェアメソッドの使用に関する問題は、スループットまたはレイテンシを最適化するためにそれらを選択する必要があることです。両方を使用することはできません。受信フレーム（rx-frames = 1）ごとに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？など）の感度の両方を確認してください。
デイブ