Queste informazioni saranno utili a quanto vogliono capire un po' meglio come funziona la loro scheda, oppure vogliono smanettare con il driver. Se non si rientra in queste categorie, allora si può anche considerare di saltare questa sezione.
Se già si è in grado di ricevere e inviare pacchetti back-to-back, allora non si possono immettere più bit di così nel cavo. Ogni scheda Ethernet moderna può ricevere pacchetti back-to-back. I driver per Linux per DP8390 (wd80x3, SMC-Ultra, 3c503, ne2000, ecc.) arrivano abbastanza vicino all'invio di pacchetti back-to-back (il limite è dato dalla reale latenza degli interrupt) e l'hardware 3c509 e AT1500 non ha problemi ad inviare automaticamente pacchetti back-to-back.
Pro: Non usa nessuna risorsa di sistema limitata, solo alcuni registri di I/O e non ha un limite a 16M.
Contro: Solitamente più bassa è la velocità di trasferimento, più la CPU attende senza far niente, e l'accesso ai pacchetti in modalità interleaved è solitamente difficile se non impossibile.
Pro: Più veloce e semplice dell'I/O programmato e inoltre permette l'accesso casuale ai pacchetti. Dove possibile, i driver per Linux calcolano il checksum dei pacchetti IP in ingresso non appena vengono copiati dalla scheda, il che risulta in un'ulteriore riduzione dell'uso della CPU rispetto ad una equivalente scheda PIO.
Contro: Usa più memoria (un grosso "contro" per utenti DOS, ma sostanzialmente non un problema sotto Linux) e blocca comunque la CPU.
Pro: Libera la CPU durante il trasferimento dei dati, può collegare assieme buffer separati, col bus ISA richiede pochissimo tempo della CPU (praticamente nulla). La maggior parte dei driver per Linux in bus-mastering usano lo schema 'copybreak' nel quale i grossi pacchetti vengono messi direttamente dalla scheda nel buffer di rete del kernel, e i pacchetti piccoli vengono invece copiati dalla CPU che li carica in cache per le elaborazioni successive.
Contro:(Applicabile solamente alle schede ISA) Per la scheda sono necessari buffer in memoria bassa e un canale di DMA. Qualsiasi dispositivo bus-master avrà problemi con altri dispositivi non bus-master che si appropriano del bus, come alcuni primitivi adattatori SCSI. Alcuni chipset per scheda madre mal progettati hanno problemi con il bus-mastering di schede ISA.
Il bus ISA può raggiungere i 5.3MB/sec (42Mb/sec), il che sembra più che adeguato per una Ethernet a 10Mbps. Nel caso di schede a 100Mbps, chiaramente è necessario un bus più veloce per sfruttare la larghezza di banda della rete.
Vi risulterà probabilmente difficile riuscire a comprare una scheda Ethernet per bus ISA di questi tempi, ma potreste anche riuscire a recuperare una scheda obsoleta o un fondo di magazzino per scopi di networking casalingo. Se proprio volete cedere al fascino del passato, potete persino utilizzare una vecchia scheda a ISA a mezzo slot (8 bit), ma siete avvertiti che la maggior parte di queste schede sono per 10Base-2.
Alcune schede a 8 bit che sono in grado di darvi prestazioni adeguate per traffici leggeri o medi sono la wd8003, la 3c503 e la ne1000. La 3c501 ha delle prestazioni disastrose, e questi poveri reperti dei tempi dell'XT, vecchi di 15 anni, dovrebbero essere evitati - Inviateli invece a chi li colleziona.
La banda passante del bus a 8 bit non limita le prestazioni più di tanto, tanto che potete aspettarvi di ottenere dai 500 agli 800kB/s in un download FTP con una scheda wd8003 installata su di un bus ISA veloce e su di una macchina (relativamente) veloce. Se il vostro traffico è diretto altrove, allora il collo di bottiglia della connessione sarà da un altra parte e l'unica differenza di velocità che voi noterete riguarderà il vostro traffico locale.
Ovviamente una interfaccia a 32 bit verso il computer è un requisito per reti a 100Mbps e oltre. Se state pensando di adottare GigE, allora i 133 megabyte al secondo del bus PCI costituiranno ancora il vostro limite.
Ma un più vecchio network a 10Mbps non ha veramente bisogno di una interfaccia a 32 bit. Si veda la sezione I/O programmato, memoria condivisa... sul perché avere una scheda Ethernet da 10Mbps montata su di un bus ISA a 8Mhz non costituisca in realtà un limite. Anche se l'avere una scheda lenta su di un bus veloce non sarà all'origine di trasferimenti di dati più veloci, solitamente essa causerà meno carico sulla CPU, il che è sempre un bene su sistemi multiutente.
Come i dati vengono ricevuti o inviati, voi potete facilmente immaginarveli mentre essi vengono copiati dall'applicazione nella memoria del kernel e da quest'ultima nella memoria della scheda. Tutto questo movimento di dati richiede tempo e risorse. Come accennato in precedenza nella sezione sul Bus Mastering DMA, una scheda ben disegnata può ridurre tutto questo copiar di dati, e il caso ideale sarebbe ovviamente "Zero Copy". Su alcune schede PCI moderne, Zero Copy diventa possibile semplicemente indicando alla scheda dove si trovano i dati ed essenzialmente dicendogli "prenditeli da te". Se si desiderano massime prestazioni in condizioni di poco traffico, allora si controlli che sia l'hardware che il driver supportino funzionamento in "Zero Copy".
Non c'è garanzia che i vostri dati viaggeranno dal computer A al computer B senza venire corrotti. Per essere sicuri che i dati siano inalterati, il mittente somma tutti i numeri che costituiscono i dati da inviare, e allega a questi il checksum calcolato. Il destinatario ricalcola questo checksum e controlla che coincida con quello ricevuto insieme ai dati. Se i due non corrispondono, il destinatario sa che i dati sono stati corrotti e scarterà il pacchetto ricevuto e relativi dati alterati.
Calcolare queste somme richiede tempo e costituisce un ulteriore carico sulla CPU del computer. Alcune delle migliori schede hanno circuiti in hardware per calcolare i checksum di ricezione e di trasmissione senza disturbare il processore principale.
Quelle schede che richiedono copia dei dati non traggono gran vantaggio dai
checksum in hardware, dato che l'operazione di somma può essere combinata
con l'operazione di copia con una minima differenza di lavoro per il processore.
Di conseguenza, checksum di trasmissione in hardware vengono usati solo in
situazioni di zero copy (come ad esempio un applicazione che chiama sendfile()),
e checksum hardware di ricezione sono al momento attuale ben più utili.
Si noti che un computer di prestazioni ragionevoli può saturare una connessione 100BaseT anche se deve calcolare i checksum in CPU e compiere operazioni di copia, per cui zero copy e checksum hardware risultano comunque solamente in un ridotto uso della CPU, si dovrebbe esaminare uno scenario GigE per vedere un aumento di prestazioni in rete.
Quando una scheda riceve un pacchetto dalla rete, solitamente la scheda richiama l'attenzione del processore con un interrupt. La CPU determina che dispositivo ha causato l'interrupt e quindi esegue l'handler d'interrupt incluso nel driver della scheda, che a sua volta rileva lo stato di interrupt della scheda per determinare che cosa la scheda volesse e, in questo caso, usa la funzione di ricezione dati inclusa nel driver e (finalmente), termina.
Adesso immaginatevi di stare continuamente ricevendo un sacco di dati, diciamo diecimila pacchetti al secondo, su un qualche server. Potete immaginarvi che la rincorsa di richieste di servizio per interrupt analoghe a quanto appena descritto causi un certo overhead, ed infatti un sacco di tempo del processore può essere facilmente risparmiato semplicemente sospendendo la generazione di interrupt e rimanendo nella funzione di ricezione del driver, dato che più o meno sa di dover servire un flusso di lavoro costante. Quest'idea sostanzialmente costituisce NAPI.
A partire dai kernel 2.6, alcuni driver hanno un opzione di configurazione per abilitare
NAPI. Un poco di documentazione al riguardo è inclusa nella directory
Documentation/networking del kernel.