Come funziona GRO (offload di ricezione generico) su NIC più avanzate?

Sono interessato a risposte particolari:

1. La scheda NIC con GRO modifica / crea TCP ACK o altri pacchetti (o questa funzione è trasparente per gli stack TCP destinatario / mittente)?
2. Dovrebbe esserci un timeout / evento in cui la scheda NIC deve passare i "segmenti incollati" allo stack TCP? Quali sono?
3. Nell'impostazione di inoltro dei pacchetti - la funzione GRO tenta anche di leggere gli ACK del ricevitore (vedi sotto perché lo sto chiedendo)?
4. Qualsiasi fonte che spieghi GRO e altre funzionalità di offload della NIC (TSO, LSO ...) meglio delle pagine man di Wikipedia e Linux sarebbe apprezzata.

Più dettagli:

Sto risolvendo un problema di prestazioni con un'implementazione IPSec. Il problema è che la larghezza di banda disponibile non è distribuita uniformemente su tutti e 4 i tunnel VPN (distribuiti approssimativamente come 200 Mbps / 200 Mbps / 1 Mbps / 1 Mbps; ogni tunnel VPN incapsula una singola connessione TCP). Di tanto in tanto in PCAP vedo che il server web rimane inattivo per circa ~ 2 secondi (in attesa di ACK). Il download riprende quando il server web ritrasmette segmenti non riconosciuti.

Il mio abbattimento interiore da PCAP è che la funzione NIC GRO incolla i pacchetti insieme ma a volte non li passa allo stack TCP in modo tempestivo e ciò sta causando i problemi.

Poiché questo server VPN non ha interfacce che interrompono le connessioni TCP ma piuttosto solo inoltra pacchetti. Quindi ho provato a disabilitare GRO e dopo ho osservato che il traffico era distribuito uniformemente su tutti i tunnel. Anche quando il ridimensionamento delle finestre TCP è disabilitato su Webserver, anche la larghezza di banda viene persino distribuita anche con GRO abilitato (ecco perché avevo la domanda n. 3).

Sto usando 2.6.32-27 Linux sul server Ubuntu 10.04 (64 bit). NIC è Intel 82571EB. Tutte le interfacce (client HTTP, client VPN, server VPN, server Web) sono collegate direttamente in catena con cavi Ethernet da 1 Gbit.

Ho trovato questo articolo incredibilmente utile: JLS2009: Offload di ricezione generico . Fornisce un'ottima panoramica di come funziona GRO.

1. Alcuni adattatori potrebbero farlo, ma anche i driver associati devono esserne consapevoli. Inoltre, i driver stessi possono farlo nel software. Dato che ciò accade prima di inserire lo stack TCP / IP del kernel, quando lo stack TCP / IP nello spazio del kernel viene inserito completamente, i pacchetti sono stati reinviati.
2. Il timeout è definito dalla specifica GRO come un 'tick' TCP / IP (incremento del campo Timestamp), che è un numero molto piccolo ma su reti veloci possono ancora essere ricevuti più pacchetti.
3. GRO entrerà in gioco dal lato ricevente dello spedizioniere, e infatti GRO è stato creato in modo che il metodo LRO più avido smetterebbe di rovinare i pacchetti sugli spedizionieri.
4. L'articolo che ho collegato sopra aiuta davvero.

Ethtool potrebbe essere in grado di abilitare / disabilitare GRO su interfacce specifiche. Dipende dalla versione.