NICポーリングと割り込みのどちらが必要ですか？
フレーム合体（NAPI）が必要な場合や、フレームごとに1つの割り込みで十分な場合に応答できるデータまたは基本的な計算を持っている人はいますか？
私のハードウェア：IBM BladeServer HS22、Broadcom 5709ギガビットNICハードウェア（MSI-X）、デュアルXeon E5530クアッドコアプロセッサ搭載。主な目的はSquidプロキシサーバーです。スイッチはNice Cisco 6500シリーズです。 。
私たちの基本的な問題は、ピーク時（100 Mbpsのトラフィック、わずか10,000 pps）にレイテンシとパケット損失が増加することです。 2.6.38への多くのチューニングとカーネルアップグレードを行ったところ、パケット損失が改善されましたが、遅延は依然として不十分です。 pingは散発的です。ローカルGbps LANでは200ミリ秒にもジャンプします。 Squidの平均応答は、CPU /メモリの負荷が良好であっても、30msから500 + msにジャンプします。
割り込みはピーク時に約15,000 /秒に上昇します。 KsoftirqdはCPUをあまり使用していません。 irqbalanceをインストールして、すべてのコア間でIRQ（eth0とeth1にそれぞれ8つ）のバランスをとっていますが、それほど効果はありません。
Intel NICにはこの種の問題があることはないようですが、ブレードシステムと固定構成ハードウェアの問題を抱えているため、Broadcomに一種の行き詰まっています。
すべてがNICが主な原因であることを示しています。現在私が考えている最良のアイデアは、待ち時間を短くし、スループットを高く維持しながら、割り込みを減らすことです。
残念ながらbnx2は、adaptive-rxまたはtxをサポートしていません。
NAPI vs適応割り込み スレッドの回答は、割り込みの緩和の概要を提供しますが、特定の回避策に最適なethtool合体設定を計算する方法に関する具体的な情報はありません。試行錯誤するより良いアプローチはありますか？
上記のワークロードとハードウェア構成にはNAPIも必要ですか？それとも、パケットごとに単一の割り込みで生きられるべきですか？
それを理解しようとするためにいくつかの読書をしていた素晴らしい質問。答えはあると言えるかもしれませんが、ヒントがいくつかあるかもしれません。
私は少なくとも「パケットごとに単一の割り込みで生きられるべきか」というあなたの質問に答えることができます。私は答えはイエスだと思います、私がアクセスできる非常に忙しいファイアウォールに基づいています：
Sar出力：
03:04:53 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s
03:04:54 PM lo 93.00 93.00 6.12 6.12 0.00 0.00 0.00
03:04:54 PM eth0 115263.00 134750.00 13280.63 41633.46 0.00 0.00 5.00
03:04:54 PM eth8 70329.00 55480.00 20132.62 6314.51 0.00 0.00 0.00
03:04:54 PM eth9 53907.00 66669.00 5820.42 21123.55 0.00 0.00 0.00
03:04:54 PM eth10 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:04:54 PM eth11 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:04:54 PM eth1 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:04:54 PM eth2 146520.00 111904.00 45228.32 12251.48 0.00 0.00 10.00
03:04:54 PM eth3 252.00 23446.00 21.34 4667.20 0.00 0.00 0.00
03:04:54 PM eth4 8.00 10.00 0.68 0.76 0.00 0.00 0.00
03:04:54 PM eth5 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:04:54 PM eth6 3929.00 2088.00 1368.01 183.79 0.00 0.00 1.00
03:04:54 PM eth7 13.00 17.00 1.42 1.19 0.00 0.00 0.00
03:04:54 PM bond0 169170.00 201419.00 19101.04 62757.00 0.00 0.00 5.00
03:04:54 PM bond1 216849.00 167384.00 65360.94 18565.99 0.00 0.00 10.00
ご覧のとおり、1秒あたりのパケット数が非常に多く、このマシンでは特別なethtoolの調整は行われていません。ああ...でもIntelチップセット。 ：\
行われた唯一のことは、インターフェイスごとに、/ proc/irq/XXX/smp_affinityを使用した手動のirq分散でした。彼らがなぜirqbalanceではなくその方法を選択したのかはわかりませんが、うまくいくようです。
質問に答えるために必要な数学についても考えましたが、変数が多すぎると思います。要約すると、私の意見では、答えは「いいえ」です。ここで結果を予測することはできないと思いますが、十分なデータキャプチャがあれば、それをより良いレベルに調整できるはずです。
そうは言っても、私の直感は、あなたが何らかの方法でハードウェアに縛られているということです...何らかのファームウェアや相互運用バグのように。
確かに、CPU、チップセット、バスの機能がそれほどトラフィック量が少ない場合と比較すると、何らかの形で割り込み管理が必要な理由はありません。 10Gbps NICを搭載した複数のRHEL 5.3 64ビットマシンがあり、それらの割り込みはそれほど悪くありません。これは100分の1です。
明らかにあなたは固定構成（私はかなり似ているHPのブレードを使用しています）を持っているので、IntelのNICを交換することは簡単なオプションですが、私はこのフォーラムや他の場所で多くの同様の問題を見つけ始めていると思いますその特定のBroadcom NICで。これまでSEサイト自体がこの種の不整合にいくつかの問題を抱えていたため、Intel NICへの交換が絶対に役立ちました。
私がお勧めするのは、単一のブレードを選び、その1台のマシンにIntelベースのアダプターを追加することです。信号を取得するには、インターコネクトまたはIBMが呼び出すものを追加する必要がありますが、同じソフトウェアセットアップを他のもので試してください。 NIC（おそらく、Broadcomを無効にできる場合）。これをテストして、どのように進むかを確認してください。ここで説明した内容には、いくつかの追加ハードウェアが必要ですが、 IBMの担当者が喜んでそれらを貸し出します。これが確実に知る唯一の方法です。見つけたものをお知らせください。これらのNICに問題がある場合は、それが奇妙なエッジケースであっても、本当に興味があります。余談ですが、まったく関係のないことについて話し合うために来週IntelとBroadcomと面会しますが、確かに彼らと話し合い、興味があることがあれば見つけたらお知らせします。
フォローアップするには、NATおよびconntrackモジュールをアンロードし、最小化されたiptablesルールセットを使用すると、素晴らしいパフォーマンスが得られます。IPVSロードバランサーは900 Mbps/150 kppsを超えています。これは、同じBroadcomを使用している間です。 bnx2チップセット。
結論として：割り込み処理は問題なく、2.6.38/3.0.xカーネルを使用するDebianのデフォルトは問題なく動作するようです。
間違いなく私は、標準のDebianパッケージを使用できるように、Intel NICを使用したいと思います。非フリーのbnx2ファームウェアとの戦いは、時間の浪費でした。
割り込みに関する問題は、割り込みがシステム全体のパフォーマンスにどのように影響するかです。割り込みはユーザーとカーネルのランド処理を先取りする可能性があり、CPUの使用量はそれほど多くないかもしれませんが、多くのコンテキスト切り替えが発生しており、これはパフォーマンスに大きな影響を与えます。 vmstatを使用して、system列、csヘッダーの割り込みと毎秒のコンテキストスイッチを確認できます（割り込みにはクロックが含まれているため、重み付けする必要があります）。小切手も。
短い直接的な答え：
ポーリングを有効にすると、コンテキストの切り替え（通常は中断のため）が現在の状態（この場合15kips）から所定の数（通常は1kから2k）に減少します。
現在、所定の数を超えるトラフィックがある場合は、ポーリングを有効にすることで、応答時間が改善されます。逆もまた真実です。コンテキストの切り替えがパフォーマンスに影響を与えない限り、これが「必要」であるとは言えません。