Problematiche di processamento ad alte prestazioni

Architetture di processamento
Panoramica sulle principali architetture di
processamento e sulle principali problematiche
relativo a L7 packet processing ad alte
prestazioni
1

Router di 1 a generazione: PC modificati
Network Interface Card
Sistema operativo
Packet buffers
PHY/MAC
Memory
CPU
PHY/MAC
PHY/MAC
Shared Bus
Routing
table
Ogni pacchetto transita
2 volte sul bus
PHY/MAC
Terminazione della linea
- Livello PHY
- Ricezione a livello di bit
Processing a livello Data-Link
- Livello Data Link
- Decapsulamento, ecc.
2
Fino ad inizio 1990
Capacità inferiore a 500Mbps
Bottleneck:
- bus condiviso
- accesso a memoria
- capacità di processing

Router di 2 a generazione
Linecard
Ogni pacchetto transita
1 volta sul bus
Sistema operativo
3
PHY/MAC
PHY/MAC
Packet
Processor
Memory
Routing
table
Packet
Processor
Memory
Input Queuing,
Output Queuing
Routing
table
Shared Bus
Spesso con
forwarding caches
Memory
Routing
table
CPU
PCI (classic): 133MBps (32 bit, 33MHz)
PCI (enhanced): 266/533MBps (32/64 bit, 66MHz)
PCI-X 1.0: 1GBps (64 bit, 133MHz)
PCI-X 2.0 (uncommon): 2.15/4.3GBps (64 bit, 266/533MHz)
PCI-E: 8GBps (250Mbps per lane, Full Duplex, max 16 lanes)
Inizio 1990
Capacità circa 5Gbps
Bottleneck:
- bus condiviso
- accesso a memoria

Router di 2 a generazione: fast/slow path
CPU
Routing
table
Memory
Linecard
Linecard
Linecard
Interconnect
Linecard
Linecard
Linecard
Slow Path
Fast Path
La capacità della card di controllo
diventa secondaria
Gli sforzi vengono concentrati
nell’ottimizzazione del Fast Path
4

Router di 3 a generazione
Linecard
Capacità di trasferimenti
multipli sulla Switching Fabric
PHY/MAC
Packet
Processor
Memory
Routing
table
Memory
Routing
table
CPU
PHY/MAC
Packet
Processor
Memory
Routing
table
Switching
Fabric
Fine 1990
Capacità (iniziale) circa 50Gbps
Bottleneck:
- accesso a memoria
- processing (forwarding + …)
5

Router di 3 a generazione: Switching Fabric
Linecard
Linecard
Linecard
Linecard
Linecard
Switching
Fabric
Arbiter
Problematiche di arbitraggio
Introduzione dello Switching Arbiter
- decisioni molto veloci (velocità pari
al throughput aggregato)
- necessità di input/output buffer
- integrazione con meccanismi di QoS
6

Switching Fabric: Ouput Queuing
Input
Input
Input
Output
Output
Output
Switching Fabric Speedup: N
Velocità di accesso ai buffer: N*R
La velocità di accesso ai buffer può essere ridotta
arbitrando l’accesso alla Switching Fabric
Questo porta a creare architetture con memorizzazione
distribuita (output + qualche altro posto)
Altra soluzione: limitare la velocità di accesso ai buffer,
e, in caso di contesa grave, scartare il pacchetto
7
Numero ingressi: N
Velocità di ogni ingresso: R

Switching Fabric: Input Queuing
Input
Input
Input
8
Arbiter
Output
Output
Output
Switching Fabric Speedup: 1
(non dipende dal numero di porte)
Velocità di accesso ai buffer: R
Head-of-Line Blocking
Si dimostra che con pacchetti distribuiti
uniformemente, l’utilizzazione max è 58.6%
HOL Blocking: il pacchetto fucsia non può
essere trasmesso anche se la porta fucsia è
libera, perchè il pacchetto giallo che lo precede
è bloccato
Necessità di un arbitro per decidere quale dei
pacchetti gialli ha diritto ad essere trasmesso
- random (necessario un random engine)
- round-robin (necessario un puntatore
all’ultima uscita servita)
- longest queue (necessario indicatori di
occupazione)
- least served (necessario un service time per
input)

Switching Fabric: Virtual Output Queuing
Output
Switching Fabric Speedup: 1
Velocità di accesso ai buffer: R
Input
Risolve l’Head-of-Line Blocking
Input
Output
Ad ogni ingresso viene mantenuta una coda per
uscita
– Ad ogni ciclo il controllore decide quali VOQ
possono inoltrare un pacchetto e configura la
crossbar
– In IQ la scelta ad ogni ciclo è tra N pacchetti
HoL
– In VOQ è tra N 2 pacchetti HoL
Input
Arbiter
Output
– Algoritmo efficiente per configurare la CrossBar
– Dato un grafo di richieste (da ogni ingresso
fino a N archi) estrarre un sottografo non output
blocking
– Attenzione: anche in VOQ da ogni ingresso
(con N HoL) può partire un solo pacchetto
9

Switching Fabric: Buffered Fabric
Inserisce il buffering all’interno della
crossbar
Se due input port vogliono accedere allo stesso
output, uno dei due pacchetti verrà
memorizzato nei buffer interni alla Fabric
L’arbitro dovrà essere in grado di pilotare la
scelta
Criticità nella gestione di QoS (la scelta diventa
complessa)
Speed-up: può essere 1
Costoso
a meno di memorie on-chip, che sono
necessariamente piccole
Soluzioni ibride (IQ, OQ, …)
Difficili da analizzare, ma comuni in pratica
10

Cisco 12816
16-slot, 40 Gigabit/slot
640Gbps
1,28 Tbps commerciali
187 Kg
180 cm
Chassis fully configured,
using all card slots, ACinput
power shelf, and 3
AC-input power supplies
4800W maximum
3 AC-input power
supplies—N+1
redundancy
11
19’’
60 cm

Router di 4 a generazione
100 metri
Bretelle ottiche
Switching Fabric
Fine 2004-
Capacità (iniziale) circa 1Tbps
Al momento un fiasco clamoroso
Linecards
Immagine tratta da Nick McKeown, "Internet Routers: Past
Present and Future“, London, June 2006.
12
Bottleneck:
- accesso a memoria
- processing (forwarding + …)

Cisco CSR-1
Chassis da 320-Gbps, 640-Gbps, e 1.2-Tbps
Slot da 40 Gbps
Multichassis, da 1,2 a 92 Tbps
Fino a 72 chassis per line card
8 chassis per fabric switching
13

Trends in Technology, Routers & Traffic
1.000.000
100.000
Line Capacity
2x / 7 months
10.000
User Traffic
2x / 12months
1.000
100
10
Router Capacity
2x / 18months
Moore’s Law
2x / 18 months
DRAM
Random Access Time
1.1x / 18months
1
1980 1983 1986 1989 1992 1995 1998 2001
Source: Nick McKeown, “Network Processors and their memory“, Network Processor Workshop, Madrid, Feb 2004.
14

Maggiori problematiche attuali
Nuovi servizi che richiedono per-packet processing
QoS, VPN, Header translation (NAT), L7 Classification, L7
inspection (es. sicurezza), Mobilità (?)
Memoria
Maggiori velocità di linea aumento delle capacità di buffering
Non è un problema sostanziale
Tempi di accesso
Negli ultimi anni il tempo di accesso alla memoria è rimasto
sostanzialmente costante
“Cache in SRAM, Store in DRAM” non è utilizzabile
Il “cache miss” non è tollerato
Consumo e dissipazione termica
15

High Speed Packet Processing
ASIC
Network Processors (es. Intel IXP)
Sistolic Processors (es. Xelerated X11)
Multicore Processors (es. Cavium Octeon)
Semantic Processors (es. Xambala)
16

Processing basato su ASICs
Le soluzioni ASIC non sono flessibili
Lunghi tempi di progettazione (18/22 mesi)
Costi elevati di implementazione (~ 1M$) e aggiornamento
Impossibilità di reagire velocemente alla domanda del mercato
Una revisione del progetto richiede ulteriori 18/20 mesi
Nuovi requisiti (“bloccare Skype”)
Bug di progetto
17

Network Processors
Vantaggi promessi
In realtà…
programmabilità
estensibilità
Difficili da programmare (assembly per avere
prestazioni accettabili)
Programmi non portabili su nuove piattaforme
semplicità
Tempo di sviluppo alto (sviluppo + tuning)
implementativa
Non così performanti
flessibilità
tempi più brevi di
sviluppo
Costano individualmente di più di un ASIC
(escludendo lo sviluppo)
Necessità di nuovi skill per la loro
programmazione
costi ridotti
Necessità di creare competenze in persone che
lavoravano in VHDL
Problematiche non banali di software concorrente
Progettati per aumentare la velocità di
processamento, e non per operazioni che sono
memory-intensive
Attualmente in fase di stallo
18

Esempio: Radisys ENP-2611
82559
10/100 Ethernet
Controller
RJ45 FastEthernet
port (control plane)
SPI-3 Bridge FPGA
IXP2400 –
600MHz
Socket 200-pin
per DRAM
(1GB)
PCI / PCI
Bridge
QDR SRAM
(16MB)
3 Gigabits
Optical Tranceiver
Ports
PM3386
Gigabit Ethernet
Controller
19

Control Flow Graph vs Data Flow Graph
Input: a, b
x= (a*(a+b)) + b
y= (a+b) /x
Output: x, y
a
DFG
b
CFG
Rappresentano:
- i canali attraverso cui i moduli
si scambiano i dati
- le dipendenze fra i diversi
moduli
+
Moduli
funzionali
R1= a+b
R2= a*R1
Il transito dei token
rappresenta il flusso dei
dati lungo la computazione
*
x= R2+b
/ +
R3= a+b
y= R3/x
y
x
20

Control Flow model vs Data Flow model
Control Flow model
Data Flow model
Basato su architettura di Von
Neumann
fetch, execute, store
Unica memoria per dati e
programma
Esecuzione guidata da Program
Counter (o Instruction Pointer)
Viene incrementato in automatico
Computazione sincrona, basata
sulla disponibilità dei dati in
ingresso ai vari moduli
Data-driven
La computazione inizia quando
arrivano i dati
Non esistono istruzioni di
Load/Store
La prossima istruzione è
determinata dall’istruzione attuale
in automatico
Le istruzioni decidono come e
dove leggere e scrivere i dati
Esistono istruzioni specifiche per
LOAD e STORE
21

Control Flow model vs Data Flow model
Control Flow Model
Dominant question is how locus of
control moves through the
program
Data may accompany the control
but it is not dominant
Reasoning is about the order of
computation
Modello di programmazione adatto
ad architetture sequenziali
Il programmatore ragiona in
termini di istruzioni, una dopo
l’altra
Data Flow Model
Dominant question is how data
moves through a collection of
(atomic) computation
As data moves, control is
activated
Reasoning is about data
availability, transformation,
latency
Maggiormente orientato verso
architetture parallele (pipeline?)
Utilizzato spesso in casi di
elaborazione semplice (e
hardcoded) con l’impiego di
blocchi elementari successivi
Es. DSP
Difficoltà con costrutti condizionali
22

Flexible High Speed Packet Processing
Due possibili soluzioni
Parallelizzazione
Moduli HW dedicati (non esplorato in questa presentazione)
PE
PE
PE
PE
PE
PE
Pool model
Pipeline model
23

Flexible High Speed Packet Processing
PE in parallelo
PE in pipeline
Facilità di programmazione
Difficoltà di programmazione
Ogni PE agisce come una CPU in
isolamento
I vari PE sono visibili al
programmatore
Il programmatore può vedere una
sola CPU (anche se il programma
gira in parallelo sui vari PE)
Il programmatore deve allocare
manualmente il programma sui
PE
Necessario comunque
prevedere primitive di
sincronizzazione
Inefficienza dal punto di vista
hardware
Quasiasi informazione di stato
deve essere condivisa tra i PE
Moduli di interconnessione tra i PE
più complessi
Es. Out of order delivery
Load balancing
Efficienza dal punto di vista
hardware
Interconnessione tra i PE più
semplice (non c’è la necessità di
crossbar, che è complicata e
richiede molto spazio sul chip)
Ogni PE ha una parte del
programma totale (instruction
memory ridotta)
Ogni PE deve mantenere l’intero
programma nella sua memoria
Le informazioni di stato possono
essere mantenute locali al modulo
(se non è richiesta la condivisione
con gli altri moduli)
24

Pool-based processing: moduli dedicati
Inefficienza nel caso di interazione con
moduli HW dedicati
PE
Ext. module
La CPU va in stallo
Aggiunta di supporto multithreaded al
PE
PE nettamente più complessi
Programmazione più complessa
T stallo
Problematiche di sincronizzazione
Necessità di conoscere i singoli tempi di
esecuzione per evitare lo stallo della CPU
Ottimizzazione difficile
Una singola variazione dei tempi di
esecuzione (es. un modulo più veloce)
scombina tutte le tempistiche
precedentemente calcolate
T
25

Pool-based processing: load balancing (1)
Queue
PE
Queue
Demux
Queue
Queue
PE
PE
Mux
Queue
PE
Parser
Hash
Lookup
Table
Load
metrics
26

Pool-based processing: load balancing (2)
Necessità di DEMUX/MUX per gestire il flusso dei
pacchetti
Bilanciamento su base sessione (più o meno)
Assegnazione delle sessioni ai PE
Fatta attraverso la lookup table
Hit: si manda il pacchetto a quel PE
Miss: si aggiunge una nuova entry e si sceglie il PE “migliore”
tramite il blocco “load metrics”
Più sessioni possono “collidere” sulla stessa hit
Necessità di cancellare vecchie sessioni
TCP FIN/RST detection non è sempre accurato, oltre che costoso
Problematica non banale
27

Pool-based processing: load balancing (3)
Meccanismi di emergenza
Sessioni grosse possono eccedere la capacità di un singolo NetPE
Può essere anche il caso di una grossa sessione dati, con invio di molti
pacchetti consecutivi
Un singolo PE lavora, gli altri rimangono in stallo
I pacchetti devono essere inoltrati in uscita con lo stesso ordine dell’ingresso
Il blocco “load metrics” può ovviare a questo problema cambiando il
comportamento del DEMUX
“Reassignment”: la sessione viene spostata sul PE con la coda più breve (lo
stato deve migrare dal vecchio al nuovo PE)
“Spraying”: i pacchetti vengono reassegnati al PE con la coda più breve
Altro…
Le informazioni di stato devono essere mantenute in una memoria condivisa
La memoria diventa un collo di bottiglia
Conclusione: sistema estremamente complesso e poco
scalabile
Alla fine, l’unica soluzione è l’utilizzo di una memoria condivisa per
mantenere lo stato
28

Packet Processing: uso di core RISC
Alcune caratteristiche dei RISC
Possibilità di esecuzione di più istruzioni in parallelo
Utile anche nel packet processing
Processing limitato nel numero di dati
Molte istruzioni su dati locali, mantenuti nei registri
Bassa capacità di I/O
Poco importante grazie alla out-of-order execution
– possibile grazie al fatto che le istruzioni sono preponderanti sul numero di accessi a
memoria
Opposto a quanto necessario nel packet processing
Accesso continuo ai pacchetti
Continue elaborazioni basate su questi dati; relativamente poche istruzioni
Processing ottimizzato su lunghi programmi (average time)
Packet Processing: processing ottimizzato su programmi corti (maximum
time)
29

Data-flow processor (systolic processor)
Modello data-driven
Si crea una pipeline in cui ogni PE ha una singola istruzione
L’istruzione è caricata a priori
Esecuzione sincrona sui vari PE
Il pacchetto si sposta da un PE all’altro
Facile calcolare le prestazioni
Wire-speed se il programma ha un numero di istruzioni inferiore al numero
di PE
Modello di programmazione
Una singola CPU con un numero massimo di istruzioni a disposizione
Modello molto semplice (è il classico Control Flow Model)
PE PE PE PE PE
Packet
30

Data flow processor: esempio
Coprocessori:
- la comunicazione è fatta tramite
un bus (o simile)
- problematiche di conflitto/non
determismo se questi sono condivisi
sulla pipeline
Implementazioni reali:
- PE con più istruzioni in parallelo (VLIW)
- PE con più istruzioni in sequenza
31
I blocchi di I/O servono per poter agganciare
eventuali coprocessori esterni alla pipeline in
base alle necessità del programma
Le posizioni di “aggancio” devono essere
stabilite a priori nel programma
Source: Xecelerated Inc.

DFP: mantenere lo stato di esecuzione
Il programma può avanzare in modo dinamico
Maggiore efficienza; le istruzioni sono schedulate dinamicamente
Complessità
Non è possibile identificare un PE che faccia una funzione specifica (e
quindi mantenere dello stato solamente al suo interno)
Ogni PE deve avere l’intero programma in memoria
Le interconnessioni verso i moduli esterni devono essere allocate
dinamicamente
Si perde in predicibilità (determinismo)
Possibilità di contese (non predicibili a priori) sulle risorse condivise
PE
PE
Packet
Program Counter
+ Flags
32

DFP e branches
Costrutti condizionali: sono uno dei punti critici
Ogni PE può essere configurato con più sequenze di esecuzione, attivabili
dinamicamente
Un “contesto” può cambiare l’attuale sequenza di esecuzione
“loop” classici sono comunque critici
33

DFP e branches: esempio
Mapping di un applicativo di forwarding di tipo DiffServ
Si noti il ridotto numero di istruzioni (load/store non sono necessarie)
20 PE x 10 blocchi 200 PE elementari; fino a 64 contesti diversi
NOP sequence
34

Data-flow processor: modello di
programmazione
Il C non è adatto
Mancano costrutti (es varie tipologie di memoria)
Una proposta: modello Classify/Action
introdotto da Agere
Un campo ancora aperto (spesso si usa l’assembly)
35