Non so se sia il posto giusto per chiedere. Potrebbe essere una domanda molto sciocca. Presumo che alcuni processori debbano elaborare i frame di dati per la commutazione / routing. I processori moderni hanno una velocità di pochi GHz. In che modo gestiscono i dati che arrivano a una velocità più rapida di quanto operano?
Risposte:
Hai perfettamente ragione, se dobbiamo usare un ciclo di istruzioni per bit, allora 10 Gbps sarebbero irrealizzabili. Quindi la prima cosa da notare è che gestiamo una parola per istruzione CPU - 64 bit.
Anche in questo caso, la cosa peggiore che possiamo fare per le prestazioni è avere l'accesso alla CPU a tutte le parole di un pacchetto. Quindi l'attenzione sulla gestione "zero-copy" dei pacchetti. Alcuni di questi trucchi sono nelle interfacce stesse: hanno DMA ("accesso diretto alla memoria") in modo che il chip del controller ethernet copi i dati nella RAM; calcolano i checksum in modo che la CPU non debba accedere a tutte le parole nel pacchetto per farlo. Alcuni di questi sono nella progettazione della struttura dei dati: stiamo attenti ad allineare i buffer dei pacchetti in modo da poterli spostare modificando la proprietà di una voce della tabella delle pagine. Alcuni di questi sono solo un'attenta programmazione per garantire che i dati dei pacchetti siano accessibili il minor numero di volte e preferibilmente non vi si acceda affatto fino al programma applicativo ricevente.
Una volta fatto tutto ciò, il prossimo limite è il sovraccarico di gestione dei pacchetti uno alla volta. Quindi ci sono un mucchio di funzioni di "offload di segmentazione" sia nel controller ethernet che nel kernel in modo da gestire gruppi di pacchetti. Ritardiamo persino il recupero dei dati dal controller Ethernet in modo che questi gruppi siano più grandi.
Finalmente abbiamo scorciatoie per casi speciali, come la chiamata sendfile () del kernel che è un percorso espresso dal disco alla rete usando la minima quantità di lavoro.
Possiamo persino instradare casi speciali (l'inoltro di pacchetti da un'interfaccia all'altra) utilizzando le funzionalità hardware delle schede di interfaccia di rete e trattando il bus PCI come un bus tra le schede anziché coinvolgere la CPU. Ciò non può essere fatto nei sistemi operativi generici, ma fornitori come Intel forniscono librerie software per implementare tali funzionalità sui propri controller Ethernet.
Allontanandoci del tutto dalle CPU, possiamo persino costruire router per scopi speciali in cui tutte le attività di inoltro avvengono nell'hardware. Poiché il bus PCI sarebbe quindi una limitazione, eseguono più bus paralleli; o anche più bus paralleli a più gruppi di interruttori a barra trasversale parallela. A un'estremità del mercato un piccolo switch Ethernet basato su TCAM sarebbe un esempio; all'altro capo del mercato, Juniper M40 sarebbe un design canonico.
Uno switch tipico inizierà a ricevere un pacchetto, cercare l'indirizzo di destinazione nel TCAM, allegare un tag con la porta di uscita al pacchetto, quindi DMA il pacchetto ancora in arrivo sul controller della porta di uscita. Si noti che se la porta di uscita è congestionata, tutto ciò che può essere fatto su questo semplice switch è di gettare via il pacchetto di ingressi. Pertanto i semplici switch non fanno una buona scelta per quando i collegamenti cambiano velocità ed è desiderabile fare la fila. Naturalmente esistono switch più sofisticati, per i quali si paga di più.
Un router tipico riceverà un pacchetto e lo terrà in una breve coda. L'indirizzo IP di destinazione verrà cercato nella RAM statica, il pacchetto verrà quindi esploso in celle per ridurre la latenza e ciascuna cella verrà inviata a un interruttore a barra incrociata sulla scheda di uscita. Quella carta riassemblerà le celle in un pacchetto e metterà in coda il pacchetto dall'interfaccia di uscita. L'accodamento sull'interfaccia di uscita può essere sofisticato.
Oggi, quasi tutta la commutazione e gran parte del routing sono gestiti in hardware, quindi la velocità del processore entra in gioco per eccezioni. Per cose come i server, è possibile che il processore non sia abbastanza veloce. Questo è stato il caso in passato. Quando uscì Ethernet da 1 Gbps, il bus utilizzato in PC e server poteva gestire solo 400 Mbps.
Cosa succede quando il processore non è abbastanza veloce è che il traffico viene eliminato. Un sacco di traffico può essere eliminato, comunque, poiché è così che viene gestita la congestione, se eseguita correttamente. Il ROSSO (Random Early Detection) è un metodo utilizzato per rilasciare casualmente i pacchetti nelle code al fine di impedire loro di riempire e far cadere i pacchetti. Questo può aiutare a prevenire la sincronizzazione TCP. Si verificano molte cadute sugli switch, in cui potrebbe essere necessario inviare più porte di una velocità a un'altra singola porta della stessa velocità.
the packet will then be exploded into cells to reduce latency?