NAPI vs Adaptive Interrupts

Adakah yang bisa menjelaskan bagaimana dua teknologi berikut digunakan untuk mengurangi interupsi overhead di bawah beban jaringan yang tinggi?

Adaptif-rx / Adaptif-tx, dan
NAPI;

Saya akan menghargai jawaban yang menjelaskan perbedaan lebih dekat ke level sumber kernel linux? Saya juga ingin mendengar bagaimana memaksa NIC ke mode polling / interupsi penggabungan saat memuat ~ 400Mbps.

Lebih banyak latar belakang:

Masalahnya tampaknya driver bnx2 dan e1000 mengabaikan perintah "ethtool -C adaptive-rx on". Ini mungkin karena driver tersebut tidak mendukung interupsi adaptif. Meskipun manual referensi Broadcom Programmer mengatakan bahwa fitur ini harus didukung oleh perangkat keras BCM5709 NIC.

Jadi saya memutuskan untuk mencoba NAPI dan mengurangi bobot dari 64 menjadi 16 di fungsi panggilan netif_napi_add () untuk memaksa NIC dalam mode polling di bawah beban yang jauh lebih rendah, tapi sayangnya itu tidak berhasil. Saya kira NAPI tidak memerlukan dukungan perangkat keras khusus di NIC, apakah itu benar?

Perangkat keras yang saya gunakan adalah BCM5709 NIC (menggunakan driver bnx2). Dan OS adalah Ubuntu 10,04. CPU-nya adalah XEON 5620.

linux-networking nic

— pengguna389238
sumber

Prinsip utama di balik moderasi interupsi adalah untuk menghasilkan kurang dari satu interupsi per frame yang diterima (atau satu interupsi per penyelesaian frame transmisi), mengurangi overhead OS yang ditemui ketika melakukan servis interupsi. Pengontrol BCM5709 mendukung beberapa metode dalam perangkat keras untuk penggabungan interupsi, termasuk:

Hasilkan interupsi setelah menerima frame X (rx-frame di ethtool)
Hasilkan interupsi ketika tidak ada lagi frame yang diterima setelah X usecs (rx-usecs di ethtool)

Masalah dengan menggunakan metode perangkat keras ini adalah Anda harus memilihnya untuk mengoptimalkan throughput atau latensi, Anda tidak dapat memiliki keduanya. Menghasilkan satu interupsi untuk setiap frame yang diterima (rx-frames = 1) meminimalkan latensi, tetapi melakukannya dengan biaya tinggi dalam hal overhead layanan interupsi. Menetapkan nilai yang lebih besar (katakanlah rx-frames = 10) mengurangi jumlah siklus CPU yang dikonsumsi dengan menghasilkan hanya satu interupsi untuk setiap sepuluh frame yang diterima, tetapi Anda juga akan menemukan latensi yang lebih tinggi untuk frame pertama dalam kelompok sepuluh.

Implementasi NAPI mencoba untuk memanfaatkan fakta bahwa lalu lintas datang dalam tandan, sehingga Anda menghasilkan interupsi segera pada frame pertama yang diterima, kemudian Anda segera beralih ke mode polling (yaitu menonaktifkan interupsi) karena lebih banyak lalu lintas akan ditutup. Setelah Anda mengumpulkan beberapa frame (16 atau 64 dalam pertanyaan Anda) atau beberapa interval waktu, maka driver akan mengaktifkan kembali interupsi dan memulai lagi.

Jika Anda memiliki beban kerja yang dapat diprediksi, maka nilai-nilai tetap dapat dipilih untuk salah satu di atas (NAPI, rx-frame, rx-usecs) yang memberi Anda trade-off yang tepat, tetapi sebagian besar beban kerja bervariasi dan Anda akhirnya membuat beberapa pengorbanan. Di sinilah bermain adaptif-rx / adaptif-tx. Idenya adalah bahwa pengemudi secara konstan memonitor beban kerja (frame yang diterima per detik, ukuran frame, dll.) Dan mengatur skema penggabungan perangkat keras untuk mengoptimalkan latensi dalam situasi lalu lintas rendah atau mengoptimalkan throughput dalam situasi lalu lintas tinggi. Ini adalah teori yang keren tetapi mungkin sulit untuk diterapkan dalam praktik. Hanya beberapa driver yang mengimplementasikannya (lihat http://fxr.watson.org/fxr/search?v=linux-2.6&string=use_adaptive_rx_coalesce ) dan driver bnx2 / e1000 tidak ada dalam daftar itu.

Untuk deskripsi yang baik tentang bagaimana setiap bidang penggabungan ethtool seharusnya berfungsi, lihat definisi untuk struktur ethtool_coalesce di alamat berikut:

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

Untuk Anda situasi tertentu (~ 400Mb / s throughput) Saya sarankan menyetel nilai rx-frame dan rx-usecs untuk pengaturan terbaik untuk beban kerja Anda. Lihatlah overhead ISR dan sensitivitas aplikasi Anda (httpd? Dll.) Terhadap latensi.

Dave

— Dave
sumber

Anda mengatakan bahwa " Implementasi NAPI berupaya memanfaatkan fakta bahwa lalu lintas datang dalam jumlah banyak, sehingga Anda menghasilkan interupsi segera pada frame pertama yang diterima , kemudian Anda langsung beralih ke mode polling ". Tetapi di wiki mengatakan bahwa NAPI tidak menggunakan interupsi perangkat keras, tidak pernah, tetapi melakukan polling setiap periode waktu tertentu : en.wikipedia.org/wiki/New_API Kutipan yang tepat: "Kernel dapat secara berkala memeriksa kedatangan paket jaringan yang masuk tanpa terganggu , yang menghilangkan overhead pemrosesan interupsi. " Dimana kebenarannya?

— Alex

@Alex Hardware interupsi harus digunakan untuk memberi tahu kernel bahwa ada lalu lintas yang akan diterima. Paket jadwal interrupt handler "gaya lama" menerima kemudian mengaktifkan kembali interupsi. Handler interrupt NAPI menonaktifkan interupsi, menjadwalkan poller, dan mengaktifkan kembali interupsi. Poller melakukan paket terima untuk sejumlah paket tertentu, dan selama ada lalu lintas ke layanan, poller tetap berjalan, tujuannya adalah untuk mencegah gangguan keras dengan selalu menarik lalu lintas dari NIC. Ketika lalu lintas mati, poller keluar dan sistem kembali menunggu interupsi.

— suprjami