Il termine è abbastanza generico e viene utilizzato molte volte in maniera impropria, per questo motivo con questo post vorrei chiarire alcuni concetti.

Per offload si intendono tutte quelle tecniche che permettono alla coppia scheda di rete (NIC) – sistema operativo di cooperare per ottimizzare la gestione del traffico di rete e delle risorse disponibili.

In particolare nei sistemi Microsoft l’offload è l’insieme, chiamato Scalable Network Pack (SNP), di queste tecniche:

1. Checksum  Offload è il calcolo del checksum di ogni singolo pacchetto è affidato alla NIC; esso può essere abilitato sia a livello 4 (TCP) che livello 3 (IP). Riduce l’utilizzo della CPU.

2. Large Send/Receive Offload (LSO o Segmentation) permette al sistema operativo di inviare alla NIC pacchetti più grandi della attuale MTU (es: 1500 byte per Ethernet). La scheda di rete si occuperà di spezzare i dati in vari segmenti di dimensioni minori alla MTU e creando nuovi header invierà direttamente i pacchetti al destinatario. Il sistema operativo è allo oscuro di quanti pacchetti siano fisicamenti inviati. Riduce il numero delle chiamate verso la scheda di rete e quindi l’utilizzo della CPU.

3. NetDMA la scheda di rete può trasferire i dati direttamente nella memoria dell’applicativo sollevando la CPU dalla copia

4. Riceve Side Scaling permette al sistema operativo di utilizzare tutte le CPU per la gestione del traffico di rete (scalabilità delle prestazioni). Ci sono determinati tipi di traffico (es: IPSEC) che non supportato questo parallelismo.

5. Chimney Offload questa tecnica delega tutta la gestione dello stato delle connessione alla scheda di rete; dopo la connessione iniziale la scheda gestisce la finestra, i timer di ritrasmissione, segmentazione, ACKs…etc..  Viene stabilito un canale di comunicazione diretto tra l’applicazione e  la scheda di rete senza passare per lo stack TCP, da questo “canale” entrano ed escono solo dati.

Necessita di un hardware che implementi un TCP OFFLOAD ENGINE (TOE)

Di seguito, un immagine datata ma molto esplicativa:

clip_image001

Fatta questa necessaria premessa, vediamo come queste tecniche si manifestano nella comunicazione reale.

E come verificarne l’effettivo utilizzo.

Catturando una traccia di rete, possiamo verificare quali di esse sono attive sulla macchina:

clip_image003

Come vediamo dalle linee evidenziate in rosso, abbiamo parecchie informazioni:

- Captured Frame Length > 1514 = lo standard classico Ethernet prevede un massimo di 1514 bytes per frame quindi se è stato catturato un pacchetto, in uscita, di dimensioni maggiori significa che la scheda ha abilitato il meccanismo di Large Send Offload, ed accetta quindi grosse quantitià di dati in un singolo frame.

NB: Non stiamo parlando di “Jumbo Frame”, che tuttavia è un meccanismo analogo ed utilizzato spesso in congiunzione con il LSO. I “jumbo frame” sono frame Ethernet con MTU pari a 9000 bytes che riducono il numero di pacchetti e quindi collisioni sulla rete.

- Checksum pari 0 o Valore errato = il valore che troviamo in questo campo è fittizio in quanto la CPU non ne calcola il vero valore demandando il lavoro alla scheda di rete. Al momento della cattura software del pacchetto noi lo intercettiamo poco prima che esso venga effettivamente passato alla scheda, quindi con i valori di checksum non ancora calcolati.

E’ interessante notare che questo vale ovviamente solo per i pacchetti inviati, in quanto i pacchetti ricevuti contengono il checksum calcolato dal mittente e verificato dal desitnatario.

In alcuni software come Network Monitor o Wireshark viene segnalato un errore “BAD CHECKSUM”, ma a questo punto sappiamo essere fittizzio e possiamo effettivamente ignorarlo (o disabilitarne il controllo).

Verificare se il Chimney Offload è utilizzato su di una connessione, è relativamente facile lato sistema operativo in quanto basta utilizzare il comando “netstat –t” (da windows 2008) ed ispezionare la colonna “Offload State”. Da una traccia di rete è molto più difficile perchè si manifesta in diversi modi, sostanzialmente vi potrebbe capitare di vedere solo il 3-way handshake e nessun’altra comunicazione in quanto avviene il tutto all’interno della scheda di rete e non nel sistema operativo dal quale catturiamo.

Per quanto riguarda il NetDMA e l’RSS non vi sono strumenti semplici per la verifica dell’effettivo utilizzo, in quanto sono parte integrante del sistema operativo ed utilizzano strutture/tecniche kernel che non sono catturabili con software di rete. Possiamo solamente verificare se sono abilitati con il seguente comando:

netsh int tcp show global

Vorrei concludere ricordandovi nuovamente che non tutte le schede supportano il Chimney Offload (richiede la specifica TOE), in particolare le schede Intel non lo supportato in quanto utilizzano una tecnica differente chiamata QuickData.

Gianluca Bertelli
Sr Support Engineer
Microsoft Enterprise Platforms Support