NAPI ve Uyarlamalı Kesmeler

Herkes yüksek ağ yükü altında kesme yükünü azaltmak için aşağıdaki iki teknolojinin nasıl kullanıldığını açıklayabilir mi?

1. Adaptive-rx / Adaptive-tx ve
2. NAPI;

Linux çekirdeği kaynak seviyesine daha yakın olan farkı açıklayan bir cevabı takdir ediyorum. Ayrıca NIC'yi ~ 400Mbps olan yükte çağırma / birleştirme modunu zorlamaya nasıl duymak istiyorum.

Daha fazla arka plan:

Sorun şu ki, bnx2 ve e1000 sürücüleri "ethtool -C adaptive-rx on" komutunu yok sayıyor gibi görünüyor. Bunun nedeni muhtemelen bu sürücülerin uyarlamalı kesintileri desteklememesidir. Broadcom Programmer'ın referans el kitabında bu özelliğin BCM5709 NIC donanımı tarafından desteklenmesi gerektiğini söylüyor.

Bu yüzden NAPI'yi denemeye ve netif_napi_add () fonksiyon çağrısında ağırlığı 64'ten 16'ya düşürmeye karar verdim, NIC'yi çok daha düşük yük altında yoklama modunda zorlamak için maalesef bu işe yaramadı. NAPI'nin NIC'de herhangi bir özel donanım desteğine ihtiyacı olmadığını tahmin ediyorum, doğru mu?

Kullandığım donanım BCM5709 NIC (bnx2 sürücüsü kullanıyor). Ve işletim sistemi Ubuntu 10.04. CPU XEON 5620'dir.

Kesme denetiminin arkasındaki ana ilke, alınan çerçeve başına birden fazla kesinti (veya iletim çerçevesi tamamlama başına bir kesinti) üreterek, kesintilere hizmet verirken karşılaşılan işletim sistemi ek yükünü azaltmaktır. BCM5709 kontrol cihazı, kesintileri birleştirmek için donanımda aşağıdakileri içeren birkaç yöntemi destekler:

• X kareleri aldıktan sonra bir kesinti oluşturun (ethtool'daki rx kareleri)
• X usecs (ettool'da rx-usecs) sonrasında daha fazla kare alınmadığında bir kesme oluşturun

Bu donanım yöntemlerini kullanmayla ilgili sorun, verimi veya gecikmeyi optimize etmek için bunları seçmeniz gerektiğidir, her ikisine de sahip olamazsınız. Alınan her bir kare için bir kesme (rx-frames = 1) oluşturmak gecikmeyi en aza indirir, ancak kesme hizmeti ek yükü açısından bunu yüksek bir maliyetle yapar. Daha büyük bir değer (rx-frames = 10 diyelim) ayarlamak, alınan her on kare için yalnızca bir kesinti oluşturarak tüketilen CPU döngüsü sayısını azaltır, ancak bu on gruptaki ilk kareler için daha yüksek bir gecikme ile karşılaşırsınız.

NAPI uygulaması, trafiğin demet halinde geldiğinden yararlanmaya çalışır, böylece alınan ilk karede hemen bir kesinti oluşturur, daha sonra daha fazla trafik yakın olacağı için hemen yoklama moduna geçersiniz (yani kesintileri devre dışı bırakır). Birkaç kare (sorunuzda 16 veya 64) veya belirli bir zaman aralığı için anket yaptıktan sonra, sürücü kesintileri yeniden etkinleştirecek ve yeniden başlayacaktır.

Öngörülebilir bir iş yükünüz varsa, yukarıdakilerden herhangi biri için (NAPI, rx-çerçeveleri, rx-usec) sabit değerler seçilebilir, ancak size doğru ödünleşimi sağlar, ancak çoğu iş yükü değişir ve bazı fedakarlıklar yaparsınız. Burada adaptive-rx / adaptive-tx devreye girer. Buradaki fikir, sürücünün iş yükünü sürekli olarak izlemesi (saniyede alınan kare sayısı, çerçeve boyutu vb.) Ve düşük trafik durumlarında gecikmeyi optimize etmek veya yüksek trafik durumlarında verimi optimize etmek için donanım kesintisi birleştirme şemasını ayarlamasıdır. Bu harika bir teori ama pratikte uygulanması zor olabilir. Sadece birkaç sürücüleri uygulamak (bkz http://fxr.watson.org/fxr/search?v=linux-2.6&string=use_adaptive_rx_coalesce ) ve bnx2 / E1000 sürücüleri o listede değil.

Her bir ettool birleştirme alanının nasıl çalışacağının iyi bir açıklaması için, aşağıdaki adresteki ethtool_coalesce yapısının tanımlarına bir göz atın:

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

Size özel durum için (~ 400Mb / s işlem hacmi) İş yükünüz için en iyi ayarlar için rx çerçevelerini ve rx-usecs değerlerini ayarlamanız önerilir. Hem ISR'nin ek yüküne hem de uygulamanızın gecikmeye duyarlılığına (httpd? Vb.) Bakın.

Dave