Quali carichi di rete richiedono polling NIC vs interrupt?

Qualcuno ha alcuni dati o calcoli di base che possono rispondere quando è richiesta la coalescenza di frame (NAPI) e quando è sufficiente un singolo interrupt per frame?

Il mio hardware: IBM BladeServer HS22, hardware Broadcom 5709 Gigabit NIC (MSI-X), con doppi processori quad-core Xeon E5530. Lo scopo principale è il server proxy Squid. Switch è una bella serie Cisco 6500.

Il nostro problema di base è che durante le ore di punta (traffico di 100 Mbps, solo 10.000 pps) aumenta la latenza e la perdita di pacchetti. Ho fatto molto tuning e aggiornamento del kernel alla 2.6.38 e ha migliorato la perdita di pacchetti ma la latenza è ancora scarsa. I ping sono sporadici; saltando anche a 200ms sulla LAN Gbps locale. La risposta media del calamaro passa da 30ms a 500 + ms anche se il carico CPU / memoria va bene.

Le interruzioni salgono a circa 15.000 / secondo durante il picco. Ksoftirqd non utilizza molta CPU; Ho installato irqbalance per bilanciare gli IRQ (8 ciascuno per eth0 ed eth1) su tutti i core, ma ciò non ha aiutato molto.

Le schede di rete Intel non sembrano mai avere questo tipo di problemi, ma a causa del sistema blade e dell'hardware di configurazione fissa, siamo un po 'bloccati con le Broadcom.

Tutto indica la NIC come il principale colpevole. L'idea migliore che ho in questo momento è provare a ridurre gli interrupt mantenendo sia la latenza bassa che la velocità effettiva elevate.

Sfortunatamente il bnx2 non supporta adattivo-rx o tx.

La risposta al thread NAPI vs Interruzioni adattive fornisce una visione d'insieme della moderazione degli interruzioni ma nessuna informazione concreta su come calcolare le impostazioni ottimali di coalescenza ettool per una determinata soluzione. Esiste un approccio migliore quindi solo tentativi ed errori?

Il carico di lavoro e la configurazione hardware sopra menzionati richiedono persino NAPI? O dovrebbe essere in grado di vivere su un singolo interrupt per pacchetto?

Grande domanda che mi ha fatto leggere un po 'per cercare di capirlo. Vorrei poter dire di avere una risposta ... ma forse alcuni suggerimenti.

Posso almeno rispondere alla tua domanda "dovrebbe essere in grado di vivere su un singolo interrupt per pacchetto". Penso che la risposta sia sì, basata su un firewall molto occupato a cui ho accesso:

Uscita 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

Come puoi vedere, conta un pacchetto molto alto al secondo, e su questa macchina non è stato fatto alcun ritocco etnico speciale. Oh ... Intel chipset, però. : \

L'unica cosa che è stata fatta è stato un bilanciamento manuale dell'irq con / proc / irq / XXX / smp_affinity, in base all'interfaccia. Non sono sicuro del motivo per cui abbiano scelto di andare in quel modo invece che con irqbalance, ma sembra funzionare.

Ho anche pensato alla matematica richiesta per rispondere alla tua domanda, ma penso che ci siano troppe variabili. Quindi ... per riassumere, secondo me, la risposta è no, non penso che tu possa prevedere i risultati qui, ma con una sufficiente acquisizione dei dati dovresti essere in grado di modificarlo a un livello migliore.

Detto questo, la mia sensazione è che tu sia in qualche modo legato all'hardware qui ... come in un firmware o in un bug di interoperabilità di qualche tipo.

Certamente date le capacità della CPU, del chipset e del bus rispetto a una quantità così bassa di traffico che non avete motivo per cui BISOGNO di alcuna forma di gestione degli interrupt. Abbiamo più macchine RHEL 5.3 a 64 bit con schede NIC da 10 Gbps e i loro interrupt non sono affatto male, questo è 100 volte inferiore.

Ovviamente hai una configurazione fissa (io uso i blade HP che sono piuttosto simili), quindi sostituire le schede di rete per Intels è ora un'opzione facile ma quello che direi è che sto iniziando a individuare una serie di problemi simili in questo forum e altrove con quella particolare scheda di rete Broadcom. Sempre i siti SE stessi hanno avuto alcuni problemi con questo tipo di incoerenza e lo scambio con le schede di rete Intel ha aiutato assolutamente.

Quello che consiglierei è scegliere un singolo blade e aggiungere un adattatore basato su Intel a quella macchina, ovviamente dovrai aggiungere un'interconnessione o qualunque cosa IBM li chiami per ottenere il segnale ma provare la stessa configurazione del software ma con questo altro NIC (probabilmente disabilitare Broadcom se è possibile). Prova questo e vedi come vai avanti, so che quello che ho descritto ha bisogno di un paio di bit di hardware extra ma immagino che il tuo rappresentante IBM ti presti felicemente. È l'unico modo per saperlo con certezza. Fateci sapere cosa scoprite, sono sinceramente interessato se c'è un problema con queste schede di rete, anche se si tratta di uno strano caso limite. Per inciso, mi incontrerò con Intel e Broadcom la prossima settimana per discutere di qualcosa di completamente estraneo, ma sicuramente ne discuterò con loro e ti farò sapere se trovo qualcosa di interessante.

La domanda sugli interrupt è come influiscono sulle prestazioni complessive del sistema. Gli interrupt possono impedire l'elaborazione della terra dell'utente e del kernel e mentre potresti non vedere molto l'uso della CPU, ci sono molti cambi di contesto che si verificano e questo è un grande successo in termini di prestazioni. È possibile utilizzare vmstate controllare la systemcolonna, l' csintestazione per gli interrupt e gli switch di contesto al secondo (gli interrupt includono l'orologio, quindi è necessario ponderarlo), vale anche la pena verificare.

La breve risposta diretta:

Se abiliti il ​​polling ridurrai i cambi di contesto (normalmente dovuti alle interruzioni) da qualunque cosa siano ora (15kips nel tuo caso) a un numero predeterminato (di solito da 1k a 2k).

Se al momento disponi di traffico al di sopra del numero predeterminato, dovresti avere tempi di risposta migliori abilitando il polling. Anche il contrario è vero. Non direi che questo è "necessario" a meno che i cambi di contesto non influiscano sulle prestazioni.

Per il follow-up: con i moduli NAT e conntrack scaricati oltre al set di regole iptables minimizzato, otteniamo prestazioni eccezionali. Il bilanciamento del carico IPVS ha superato i 900 Mbps / 150 kpps. Questo è ancora usando gli stessi chipset Broadcom bnx2.

Per concludere: la gestione degli interrupt sembra a posto e le impostazioni predefinite per Debian con il kernel 2.6.38 / 3.0.x sembrano funzionare in modo accettabile.

Sicuramente preferirei usare le schede di rete Intel in modo da poter usare i pacchetti Debian standard. Combattere il firmware bnx2 non gratuito è stato un enorme spreco di tempo.