Iniziamo senza napi e interrompiamo l'unione.
Il primo caso:livelock. Ciò significa che quando molti interrupt vengono inviati continuamente dal processo server, la CPU elabora solo gli interrupt e non consente mai l'esecuzione di un processo a livello utente e il servizio effettivo delle richieste. Per questo, creiamo napi, che lo gestisce in modalità ibrida (interrupt + polling). Quando si verifica un'interruzione, gestiscila ed esegui il polling per un po' per risolvere le richieste di sottosequenza.
Il secondo caso:l'ottimizzazione. Prima di generare un interrupt, un dispositivo attende un po' prima di consegnare l'interrupt alla CPU. Durante l'attesa, altre richieste potrebbero presto essere completate e quindi più interruzioni possono essere unite in un'unica consegna di interruzioni, riducendo così il sovraccarico dell'elaborazione dell'interruzione.
Per concludere, non ci sono conflitti tra di loro. E sono per casi diversi sebbene napi possa anche ottimizzare l'overhead della CPU.
Ref:Principi di progettazione di sistemi informatici.
Considero NAPI come una forma di unione di interruzioni. Penso che la tua domanda possa derivare da un malinteso su NAPI. Prima di tutto, gli interrupt sono coinvolti con NAPI. Inoltre, il sondaggio del NAPI in realtà non è "vano". Ricorda, per NAPI, l'idea è che il traffico ad alto throughput sia esplosivo. NAPI "si avvia" solo dopo che si verifica un "interruzione di pacchetto ricevuto".
Ecco una rapida panoramica di come NAPI dovrebbe essere utilizzato:
Il kernel dà il via all'interrupt "pacchetto ricevuto", rilevato da un driver di dispositivo di rete che utilizza NAPI. Il driver del dispositivo di rete quindi disabilita gli interrupt relativi alla ricezione dei pacchetti e utilizzando NAPI, dice al sottosistema di rete Linux di eseguire il polling del driver del dispositivo. La funzione poll è implementata dal driver del dispositivo, viene passata al sottosistema di rete e contiene il gestore dei pacchetti del driver del dispositivo. Dopo che è stato ricevuto un numero sufficiente di pacchetti o è stato raggiunto un timeout, gli interrupt di ricezione dei pacchetti vengono riattivati e tutto ricomincia da capo.
Quindi NAPI è fondamentalmente solo un'API centralizzata nel sottosistema di rete Linux per supportare l'unione degli interrupt per ridurre le situazioni di livelock di ricezione. NAPI offre agli sviluppatori di driver di dispositivo un framework pulito per l'unione degli interrupt. NAPI non funziona sempre, ma si verifica solo quando il traffico viene effettivamente ricevuto, il che lo rende essenzialmente uno schema di unione di interruzioni... Almeno secondo me.
Nota :Questo era tutto nel contesto di un driver di dispositivo di rete che utilizza NAPI, ma in realtà NAPI può essere utilizzato per qualsiasi tipo di interruzione. Anche questo è uno dei vantaggi di NAPI.
Se ci sono errori nella mia comprensione, sentiti libero di segnalarmeli!