Nuovo appuntamento con la Rubrica Firmware Reload. Il protocollo TCP/IP è ormai un aspetto consolidato e utilizzato nelle sue varianti più disparate, in differenti contesti operativi. Non poteva di certo mancare la sua applicabilità allo standard PCI Express.
Introduzione
Il bus PCI Express è una soluzione altamente scalabile, di tipo commutato e point-to-point: una soluzione di I/O di tipo seriale che risulta retro-compatibile. PCI Express mantiene il modello load store del PCI, senza la segnalazione, ad esempio, degli interrupt e dove tutte le informazioni sono trasmesse in band, come la Quality of Service (QOS) o l’Hot-Plug/Hot-Swap, insieme all’integrità dei dati e la gestione degli errori. Un approccio di questo tipo permette una riduzione del numero delle interconnessioni fisiche: ogni linea PCI Express trasmette, in una direzione, 2,5 GB/s.
Il PCI Express, indicato a volte come PCIe, è un’implementazione del bus PCI con un differente livello di comunicazione: non più basato sul concetto di bus, ma su un’architettura a stella dove le singole componenti comunicano in maniera seriale. Una scelta di questo tipo assicura una maggiore velocità di comunicazione con minimi impatti sulle periferiche: in questo modo possono essere facilmente adattate. In realtà, le applicazioni di tipo video, allo scopo di offrire un pieno supporto verso il bus PCI Express, hanno richiesto diversi cambiamenti in termini di logica hardware al fine di gestire il diverso protocollo di comunicazione. In effetti, il bus PCIe rappresenta un deciso cambiamento rispetto alle scelte operate su bus AGP. Basandosi su un trasferimento dei dati seriale, a differenza di quello parallelo del bus PCI, si semplifica il layout del PCB delle schede madri.
Non solo, con una scelta di questo tipo si consente di offrire una maggiore modularità perché è possibile aggregare più canali per aumentare la banda passante disponibile o per supportare particolari configurazioni come l’utilizzo di due o più schede video. In termini di banda, ciascun canale è indipendente da quella degli altri. Un singolo canale, chiamato x1, offre una band width full duplex di 266 MBytes/sec. I connettori PCI-ex per schede video sono generalmente costituiti da 16 canali, dunque 16x, offrendo una velocità doppia rispetto allo standard AGP 8x. La Tabella 1 mostra le differenze tra bus.
Tabella 1: prestazioni dei bus
PCI EXPRESS CON TCP/IP
La diffusione delle sempre più stringenti necessità elaborative, assieme a una maggiore richiesta di trasferimento dei dati, ha permesso di definire nuove architetture dove le operazioni di elaborazione sono distribuite e assegnate ai vari elementi presenti nel sistema al fine di distribuire il carico e ricavare un throughput migliore. Un sistema di questo tipo deve essere strettamente coordinato e i diversi elementi devono essere strettamente integrati allo scopo di ottenere il risultato desiderato: l’obiettivo è gestire un insieme di elementi in grado di assicurare il carico elaborativo richiesto.
In realtà, da un punto di vista pratico, il tutto deve rispettare un’esigenza del tutto legittima: l’ambiente di lavoro può essere costituito da server fisicamente posti in differenti punti geografici strettamente disgiunti fisicamente ma in modo logico strettamente accoppiati. Per rispettare questa esigenza è necessario introdurre un meccanismo di interconnessione. In pratica diventa necessario definire dei sistemi di comunicazione, una specie di rete tradizionale, al fine di condividere le risorse e lavorare in modo coordinato. Infatti, in un’applicazione di questo tipo può essere necessario accedere, ad esempio, a grandi quantità di dati tramite NAS. Tipicamente, si risponde a questa particolare esigenza introducendo il concetto di Root Complex Processor: un’architettura che consente di mettere insieme risorse hardware differenti.
Infatti, con questa particolare architettura si introduce il concetto di I/O gerarchico che permette di mettere insieme CPU/Memoria di un particolare sottosistema verso un dispositivo I/O, ovvero un root complex, più end point (dispositivi di I/O), uno switch e un bridge PCI Express verso PCI/PCI-X interconnessi. Questa soluzione permette di sfruttare tutte le caratteristiche del PCI Express, ossia point-to-point, low-overhead, low-latency ed efficienza: questo protocollo si basa su una serie di transazioni tra Data e Physical layers. Una rete di questo tipo può essere realizzata offrendo, attraverso uno specifico protocollo universalmente riconosciuto, interfacce che permettono di accedere e gestire i differenti dispositivi fisici dove i diversi controller si preoccupano di gestire gli end point presenti.
È possibile utilizzare il TCP/IP, protocollo di comunicazione di rete messo a punto prima dell’avvento del PCI Express ma universalmente utilizzato in ogni contesto operativo in diverse forme e varianti, perché offre un meccanismo di transazione, un collegamento dei dati e strati fisici flessibili. I dati originati a livello applicazione sono trasformati in pacchetti TCP/IP e quindi incapsulati in pacchetti PCI Express. Questi pacchetti sono inviati al controllore Ethernet che provvede a deimpacchettare il pacchetto TCP/IP per rispettare il meccanismo definito in PCI Express per poi re-impacchettarli per inviarli su trame Ethernet con supporto fisico da 10 Gigabit.
Esistono diverse proposte di questo tipo: da un approccio con ExpressNet fino ad arrivare al driver ixgbe offerto da alcune distribuzioni Linux, è opportuno ricordare che ixgbe è un driver PCI Express per Ethernet a 10 Gigabit che supporta i diversi controller Ethernet Intel 82598 e 82599 da 10 Gigabit. Al momento, il driver supporta la versione 2.6.x del kernel di Linux incluso il supporto verso Itanium® 2, x86_64, i686 e PPC. Il flusso di controllo, Ethernet Flow Control IEEE 802.3, può essere configurato con ethtool al fine di abilitare la ricezione e la trasmissione di PAUSE frame per ixgbe. Quando la trasmissione viene attivata, vengono generati PAUSE frame ogni volta che il buffer di ricezione supera una soglia predefinita.
Al contrario, quando è abilitata la ricezione, l’unità di trasmissione si fermerà per un tempo specificato, ovvero a ogni PAUSE frame ricevuto. Il flusso di controllo è abilitato per default e per disabilitarlo è necessario, attraverso ethtool, inserire il comando: ethtool -A eth? autoneg off rx off tx off. In effetti, il driver utilizza ethtool per configurare e condurre la verifica funzionale del sistema sotto test, inclusa la possibilità di ottenere dati statistici. Ethtool può essere prelevato dal sito di riferimento: http://ftp.kernel.org/pub/software/network/ ethtool/. È anche opportuno ricordare che la configurazione di un driver di rete è un’operazione delicata perché la sua impostazione incide in modo diretto sulle prestazioni dell’intera applicazione. Tipicamente, nel processo di configurazione si aggiunge una linea alias in /etc/modules.conf oppure etc/modprobe. conf, e la modifica di script utilizzati durante l’avvio del sistema. Molte distribuzioni Linux comprendono diversi strumenti che permettono di agevolare questa operazione, ecco perché diventa necessario consultare la documentazione a corredo di ciascuna distribuzione. La Figura 1 pone in evidenza il flusso software tra i differenti livelli presenti per trasmettere un data buffer con il driver ixgbe, mentre i listati mostrano l’approccio utilizzato così come raffigurato in figura.
Figura 1: Il driver ixgbe
Il Riquadro 1 riporta, così come ha messo in evidenza Intel stessa, la procedura utilizzata per sfruttare il driver ixgbe.
EXPRESSNET
ExpressNet è un software di comunicazione progettato per i sistemi multiprocessore, leggermente accoppiato mediante uno standard PCI Express, la Figura 2 e la 3 pongono in evidenza questo modello architetturale. In questa configurazione ogni periferica deve avere un driver compatibile con ExpressNet con le relative interfacce.
Figura 2: ExpressNet
Figura 3: ExpressNet, una particolare soluzione proposta
In questa soluzione sono possibili due differenti approcci: o accedere alle risorse con un protocollo TCP/IP o attraverso il meccanismo DDT, ossia Direct Data Transfer. I dispositivi presenti sul bus PCI si identificano o come switch/bridge o come end point in base alla loro intestazione, o header format. A questo riguardo, gli end point si identificano in base alla loro enumerazione e al software di discovery con un Header del tipo “TYPE 0 Header”, mentre il bridge si identifica come “TYPE 1 Header”. Il bridge, per definizione, è utilizzato per fornire un percorso tra i diversi bus indipendenti. Così, il Non-Transparent e Transparent Bridges sono funzionalmente la stessa cosa anche se si differenziano perché il Non-Transparent Bridges si maschera come un end point al processo di discovery. Ai dispositivi presenti si associano attraverso un codice o Class Code. Un bridge PCI-PCI Transparent utilizza un class code pari a 0x060400, mentre un Non-Transparent bridge identifica sé stesso come un Ram controller con un class code di 0x050000. Questa particolare associazione ha un senso; infatti, con questa nomenclatura si riflette il suo utilizzo tipico come spazio di memoria contenente dispositivi I/O mappati in memoria da un dominio a un altro (in base al loro indirizzo).
In ambito PCI sono presenti due tipi di operazioni: Posted e non Posted dove le transazioni Posted non richiedono un completamento. Nel PCI il traffico di routing può essere gestito da tre schemi distinti: indirizzo di routing, ID di routing e routing implicito. Il campo Tipo in uno TLP ricevuto indica se il pacchetto deve essere instradato utilizzando un indirizzo, ID, o implicitamente. Al contrario, l’Indirizzo di routing utilizza l’indirizzo situato all’interno del suo BARS: questa particolarità permette di verificare se l’indirizzo rientra in quelli previsti e di inoltrare il messaggio o, in caso contrario, di respingere il pacchetto come non supportato. L’ID instradamento, infine, è basato su una posizione logica (Numero Bus, Numero dispositivo, Numero di funzione) di un dispositivo all’interno della topologia PCI bus. Le Figure 2 e 3 pongono in evidenza l’architettura dell’ExpressNet.
Infatti, dalle figure notiamo che l’ExpressNet supporta protocolli come TCP/IP, PXI-MC e MPI e, al fine di supportare il protocollo ExpressNet 2.0, è necessario utilizzare la libreria libXnet2.0. Tutte le topologie presenti richiedono un gestore per memorizzare e aggiornare il meccanismo di comunicazione. In effetti, questi schemi di instradamento sono essenziali per gestire un software di comunicazione basata su più livelli come il protocollo TCP/IP: utilizzare l’indirizzo o un ID di routing implica la necessità di utilizzare una mappa delle risorse per permettere una comunicazione distribuita. Infatti, il tutto si basa su una struttura a lista collegata, linked list, contenente informazioni come la base e la lunghezza di ciascuna finestra di memoria presente nella topologia utilizzata. Non solo, è anche necessario disporre di un particolare meccanismo di protezione per isolare, funzionalmente, ciascuna risorsa e proteggere la lista delle mappe. Ogni dominio locale deve poter comunicare il desiderio di cambiare la sua mappa delle risorse o poter accertare l’indirizzo di una nuova risorsa.
