Problematiche di processamento ad alte prestazioni
Problematiche di processamento ad alte prestazioni
Problematiche di processamento ad alte prestazioni
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Architetture <strong>di</strong> <strong>processamento</strong><br />
Panoramica sulle principali architetture <strong>di</strong><br />
<strong>processamento</strong> e sulle principali problematiche<br />
relativo a L7 packet processing <strong>ad</strong> <strong>alte</strong><br />
<strong>prestazioni</strong><br />
1
Router <strong>di</strong> 1 a generazione: PC mo<strong>di</strong>ficati<br />
Network Interface Card<br />
Sistema operativo<br />
Packet buffers<br />
PHY/MAC<br />
Memory<br />
CPU<br />
PHY/MAC<br />
PHY/MAC<br />
Shared Bus<br />
Routing<br />
table<br />
Ogni pacchetto transita<br />
2 volte sul bus<br />
PHY/MAC<br />
Terminazione della linea<br />
- Livello PHY<br />
- Ricezione a livello <strong>di</strong> bit<br />
Processing a livello Data-Link<br />
- Livello Data Link<br />
- Decapsulamento, ecc.<br />
2<br />
Fino <strong>ad</strong> inizio 1990<br />
Capacità inferiore a 500Mbps<br />
Bottleneck:<br />
- bus con<strong>di</strong>viso<br />
- accesso a memoria<br />
- capacità <strong>di</strong> processing
Router <strong>di</strong> 2 a generazione<br />
Linecard<br />
Ogni pacchetto transita<br />
1 volta sul bus<br />
Sistema operativo<br />
3<br />
PHY/MAC<br />
PHY/MAC<br />
Packet<br />
Processor<br />
Memory<br />
Routing<br />
table<br />
Packet<br />
Processor<br />
Memory<br />
Input Queuing,<br />
Output Queuing<br />
Routing<br />
table<br />
Shared Bus<br />
Spesso con<br />
forwar<strong>di</strong>ng caches<br />
Memory<br />
Routing<br />
table<br />
CPU<br />
PCI (classic): 133MBps (32 bit, 33MHz)<br />
PCI (enhanced): 266/533MBps (32/64 bit, 66MHz)<br />
PCI-X 1.0: 1GBps (64 bit, 133MHz)<br />
PCI-X 2.0 (uncommon): 2.15/4.3GBps (64 bit, 266/533MHz)<br />
PCI-E: 8GBps (250Mbps per lane, Full Duplex, max 16 lanes)<br />
Inizio 1990<br />
Capacità circa 5Gbps<br />
Bottleneck:<br />
- bus con<strong>di</strong>viso<br />
- accesso a memoria
Router <strong>di</strong> 2 a generazione: fast/slow path<br />
CPU<br />
Routing<br />
table<br />
Memory<br />
Linecard<br />
Linecard<br />
Linecard<br />
Interconnect<br />
Linecard<br />
Linecard<br />
Linecard<br />
Slow Path<br />
Fast Path<br />
La capacità della card <strong>di</strong> controllo<br />
<strong>di</strong>venta secondaria<br />
Gli sforzi vengono concentrati<br />
nell’ottimizzazione del Fast Path<br />
4
Router <strong>di</strong> 3 a generazione<br />
Linecard<br />
Capacità <strong>di</strong> trasferimenti<br />
multipli sulla Switching Fabric<br />
PHY/MAC<br />
Packet<br />
Processor<br />
Memory<br />
Routing<br />
table<br />
Memory<br />
Routing<br />
table<br />
CPU<br />
PHY/MAC<br />
Packet<br />
Processor<br />
Memory<br />
Routing<br />
table<br />
Switching<br />
Fabric<br />
Fine 1990<br />
Capacità (iniziale) circa 50Gbps<br />
Bottleneck:<br />
- accesso a memoria<br />
- processing (forwar<strong>di</strong>ng + …)<br />
5
Router <strong>di</strong> 3 a generazione: Switching Fabric<br />
Linecard<br />
Linecard<br />
Linecard<br />
Linecard<br />
Linecard<br />
Switching<br />
Fabric<br />
Arbiter<br />
<strong>Problematiche</strong> <strong>di</strong> arbitraggio<br />
Introduzione dello Switching Arbiter<br />
- decisioni molto veloci (velocità pari<br />
al throughput aggregato)<br />
- necessità <strong>di</strong> input/output buffer<br />
- integrazione con meccanismi <strong>di</strong> QoS<br />
6
Switching Fabric: Ouput Queuing<br />
Input<br />
Input<br />
Input<br />
Output<br />
Output<br />
Output<br />
Switching Fabric Speedup: N<br />
Velocità <strong>di</strong> accesso ai buffer: N*R<br />
La velocità <strong>di</strong> accesso ai buffer può essere ridotta<br />
arbitrando l’accesso alla Switching Fabric<br />
Questo porta a creare architetture con memorizzazione<br />
<strong>di</strong>stribuita (output + qualche altro posto)<br />
Altra soluzione: limitare la velocità <strong>di</strong> accesso ai buffer,<br />
e, in caso <strong>di</strong> contesa grave, scartare il pacchetto<br />
7<br />
Numero ingressi: N<br />
Velocità <strong>di</strong> ogni ingresso: R
Switching Fabric: Input Queuing<br />
Input<br />
Input<br />
Input<br />
8<br />
Arbiter<br />
Output<br />
Output<br />
Output<br />
Switching Fabric Speedup: 1<br />
(non <strong>di</strong>pende dal numero <strong>di</strong> porte)<br />
Velocità <strong>di</strong> accesso ai buffer: R<br />
He<strong>ad</strong>-of-Line Blocking<br />
Si <strong>di</strong>mostra che con pacchetti <strong>di</strong>stribuiti<br />
uniformemente, l’utilizzazione max è 58.6%<br />
HOL Blocking: il pacchetto fucsia non può<br />
essere trasmesso anche se la porta fucsia è<br />
libera, perchè il pacchetto giallo che lo precede<br />
è bloccato<br />
Necessità <strong>di</strong> un arbitro per decidere quale dei<br />
pacchetti gialli ha <strong>di</strong>ritto <strong>ad</strong> essere trasmesso<br />
- random (necessario un random engine)<br />
- round-robin (necessario un puntatore<br />
all’ultima uscita servita)<br />
- longest queue (necessario in<strong>di</strong>catori <strong>di</strong><br />
occupazione)<br />
- least served (necessario un service time per<br />
input)
Switching Fabric: Virtual Output Queuing<br />
Output<br />
Switching Fabric Speedup: 1<br />
Velocità <strong>di</strong> accesso ai buffer: R<br />
Input<br />
Risolve l’He<strong>ad</strong>-of-Line Blocking<br />
Input<br />
Output<br />
Ad ogni ingresso viene mantenuta una coda per<br />
uscita<br />
– Ad ogni ciclo il controllore decide quali VOQ<br />
possono inoltrare un pacchetto e configura la<br />
crossbar<br />
– In IQ la scelta <strong>ad</strong> ogni ciclo è tra N pacchetti<br />
HoL<br />
– In VOQ è tra N 2 pacchetti HoL<br />
Input<br />
Arbiter<br />
Output<br />
– Algoritmo efficiente per configurare la CrossBar<br />
– Dato un grafo <strong>di</strong> richieste (da ogni ingresso<br />
fino a N archi) estrarre un sottografo non output<br />
blocking<br />
– Attenzione: anche in VOQ da ogni ingresso<br />
(con N HoL) può partire un solo pacchetto<br />
9
Switching Fabric: Buffered Fabric<br />
<br />
Inserisce il buffering all’interno della<br />
crossbar<br />
<br />
<br />
<br />
Se due input port vogliono accedere allo stesso<br />
output, uno dei due pacchetti verrà<br />
memorizzato nei buffer interni alla Fabric<br />
L’arbitro dovrà essere in gr<strong>ad</strong>o <strong>di</strong> pilotare la<br />
scelta<br />
Criticità nella gestione <strong>di</strong> QoS (la scelta <strong>di</strong>venta<br />
complessa)<br />
Speed-up: può essere 1<br />
<br />
<br />
Costoso<br />
a meno <strong>di</strong> memorie on-chip, che sono<br />
necessariamente piccole<br />
Soluzioni ibride (IQ, OQ, …)<br />
<br />
Difficili da analizzare, ma comuni in pratica<br />
10
Cisco 12816<br />
16-slot, 40 Gigabit/slot<br />
640Gbps<br />
1,28 Tbps commerciali<br />
187 Kg<br />
180 cm<br />
Chassis fully configured,<br />
using all card slots, ACinput<br />
power shelf, and 3<br />
AC-input power supplies<br />
4800W maximum<br />
3 AC-input power<br />
supplies—N+1<br />
redundancy<br />
11<br />
19’’<br />
60 cm
Router <strong>di</strong> 4 a generazione<br />
100 metri<br />
Bretelle ottiche<br />
Switching Fabric<br />
Fine 2004-<br />
Capacità (iniziale) circa 1Tbps<br />
Al momento un fiasco clamoroso<br />
Linecards<br />
Immagine tratta da Nick McKeown, "Internet Routers: Past<br />
Present and Future“, London, June 2006.<br />
12<br />
Bottleneck:<br />
- accesso a memoria<br />
- processing (forwar<strong>di</strong>ng + …)
Cisco CSR-1<br />
<br />
<br />
<br />
Chassis da 320-Gbps, 640-Gbps, e 1.2-Tbps<br />
Slot da 40 Gbps<br />
Multichassis, da 1,2 a 92 Tbps<br />
Fino a 72 chassis per line card<br />
8 chassis per fabric switching<br />
13
Trends in Technology, Routers & Traffic<br />
1.000.000<br />
100.000<br />
Line Capacity<br />
2x / 7 months<br />
10.000<br />
User Traffic<br />
2x / 12months<br />
1.000<br />
100<br />
10<br />
Router Capacity<br />
2x / 18months<br />
Moore’s Law<br />
2x / 18 months<br />
DRAM<br />
Random Access Time<br />
1.1x / 18months<br />
1<br />
1980 1983 1986 1989 1992 1995 1998 2001<br />
Source: Nick McKeown, “Network Processors and their memory“, Network Processor Workshop, M<strong>ad</strong>rid, Feb 2004.<br />
14
Maggiori problematiche attuali<br />
<br />
Nuovi servizi che richiedono per-packet processing<br />
QoS, VPN, He<strong>ad</strong>er translation (NAT), L7 Classification, L7<br />
inspection (es. sicurezza), Mobilità (?)<br />
<br />
Memoria<br />
Maggiori velocità <strong>di</strong> linea aumento delle capacità <strong>di</strong> buffering<br />
<br />
Non è un problema sostanziale<br />
Tempi <strong>di</strong> accesso<br />
<br />
<br />
Negli ultimi anni il tempo <strong>di</strong> accesso alla memoria è rimasto<br />
sostanzialmente costante<br />
“Cache in SRAM, Store in DRAM” non è utilizzabile<br />
<br />
Il “cache miss” non è tollerato<br />
<br />
Consumo e <strong>di</strong>ssipazione termica<br />
15
High Speed Packet Processing<br />
<br />
<br />
ASIC<br />
Network Processors (es. Intel IXP)<br />
Sistolic Processors (es. Xelerated X11)<br />
<br />
<br />
Multicore Processors (es. Cavium Octeon)<br />
Semantic Processors (es. Xambala)<br />
16
Processing basato su ASICs<br />
<br />
Le soluzioni ASIC non sono flessibili<br />
Lunghi tempi <strong>di</strong> progettazione (18/22 mesi)<br />
Costi elevati <strong>di</strong> implementazione (~ 1M$) e aggiornamento<br />
Impossibilità <strong>di</strong> reagire velocemente alla domanda del mercato<br />
Una revisione del progetto richiede ulteriori 18/20 mesi<br />
<br />
<br />
Nuovi requisiti (“bloccare Skype”)<br />
Bug <strong>di</strong> progetto<br />
17
Network Processors<br />
<br />
Vantaggi promessi<br />
<br />
In realtà…<br />
<br />
<br />
programmabilità<br />
estensibilità<br />
<br />
<br />
Difficili da programmare (assembly per avere<br />
<strong>prestazioni</strong> accettabili)<br />
Programmi non portabili su nuove piattaforme<br />
<br />
semplicità<br />
<br />
Tempo <strong>di</strong> sviluppo alto (sviluppo + tuning)<br />
implementativa<br />
<br />
Non così performanti<br />
<br />
flessibilità<br />
tempi più brevi <strong>di</strong><br />
sviluppo<br />
Costano in<strong>di</strong>vidualmente <strong>di</strong> più <strong>di</strong> un ASIC<br />
(escludendo lo sviluppo)<br />
Necessità <strong>di</strong> nuovi skill per la loro<br />
programmazione<br />
<br />
costi ridotti<br />
<br />
Necessità <strong>di</strong> creare competenze in persone che<br />
lavoravano in VHDL<br />
<br />
<strong>Problematiche</strong> non banali <strong>di</strong> software concorrente<br />
Progettati per aumentare la velocità <strong>di</strong><br />
<strong>processamento</strong>, e non per operazioni che sono<br />
memory-intensive<br />
<br />
Attualmente in fase <strong>di</strong> stallo<br />
18
Esempio: Ra<strong>di</strong>sys ENP-2611<br />
82559<br />
10/100 Ethernet<br />
Controller<br />
RJ45 FastEthernet<br />
port (control plane)<br />
SPI-3 Bridge FPGA<br />
IXP2400 –<br />
600MHz<br />
Socket 200-pin<br />
per DRAM<br />
(1GB)<br />
PCI / PCI<br />
Bridge<br />
QDR SRAM<br />
(16MB)<br />
3 Gigabits<br />
Optical Tranceiver<br />
Ports<br />
PM3386<br />
Gigabit Ethernet<br />
Controller<br />
19
Control Flow Graph vs Data Flow Graph<br />
Input: a, b<br />
x= (a*(a+b)) + b<br />
y= (a+b) /x<br />
Output: x, y<br />
a<br />
DFG<br />
b<br />
CFG<br />
Rappresentano:<br />
- i canali attraverso cui i moduli<br />
si scambiano i dati<br />
- le <strong>di</strong>pendenze fra i <strong>di</strong>versi<br />
moduli<br />
+<br />
Moduli<br />
funzionali<br />
R1= a+b<br />
R2= a*R1<br />
Il transito dei token<br />
rappresenta il flusso dei<br />
dati lungo la computazione<br />
*<br />
x= R2+b<br />
/ +<br />
R3= a+b<br />
y= R3/x<br />
y<br />
x<br />
20
Control Flow model vs Data Flow model<br />
<br />
Control Flow model<br />
<br />
Data Flow model<br />
Basato su architettura <strong>di</strong> Von<br />
<br />
Neumann<br />
<br />
fetch, execute, store<br />
Unica memoria per dati e<br />
programma<br />
Esecuzione guidata da Program<br />
Counter (o Instruction Pointer)<br />
<br />
Viene incrementato in automatico<br />
Computazione sincrona, basata<br />
sulla <strong>di</strong>sponibilità dei dati in<br />
ingresso ai vari moduli<br />
<br />
<br />
Data-driven<br />
La computazione inizia quando<br />
arrivano i dati<br />
Non esistono istruzioni <strong>di</strong><br />
Lo<strong>ad</strong>/Store<br />
La prossima istruzione è<br />
determinata dall’istruzione attuale<br />
in automatico<br />
<br />
Le istruzioni decidono come e<br />
dove leggere e scrivere i dati<br />
<br />
Esistono istruzioni specifiche per<br />
LOAD e STORE<br />
21
Control Flow model vs Data Flow model<br />
<br />
<br />
Control Flow Model<br />
<br />
<br />
<br />
Dominant question is how locus of<br />
control moves through the<br />
program<br />
Data may accompany the control<br />
but it is not dominant<br />
Reasoning is about the order of<br />
computation<br />
Modello <strong>di</strong> programmazione <strong>ad</strong>atto<br />
<strong>ad</strong> architetture sequenziali<br />
Il programmatore ragiona in<br />
termini <strong>di</strong> istruzioni, una dopo<br />
l’altra<br />
<br />
Data Flow Model<br />
<br />
Dominant question is how data<br />
moves through a collection of<br />
(atomic) computation<br />
As data moves, control is<br />
activated<br />
Reasoning is about data<br />
availability, transformation,<br />
latency<br />
Maggiormente orientato verso<br />
architetture parallele (pipeline?)<br />
Utilizzato spesso in casi <strong>di</strong><br />
elaborazione semplice (e<br />
hardcoded) con l’impiego <strong>di</strong><br />
blocchi elementari successivi<br />
<br />
<br />
Es. DSP<br />
Difficoltà con costrutti con<strong>di</strong>zionali<br />
22
Flexible High Speed Packet Processing<br />
<br />
Due possibili soluzioni<br />
Parallelizzazione<br />
Moduli HW de<strong>di</strong>cati (non esplorato in questa presentazione)<br />
PE<br />
PE<br />
PE<br />
PE<br />
PE<br />
PE<br />
Pool model<br />
Pipeline model<br />
23
Flexible High Speed Packet Processing<br />
<br />
PE in parallelo<br />
<br />
PE in pipeline<br />
<br />
Facilità <strong>di</strong> programmazione<br />
<br />
Difficoltà <strong>di</strong> programmazione<br />
<br />
Ogni PE agisce come una CPU in<br />
isolamento<br />
I vari PE sono visibili al<br />
programmatore<br />
<br />
Il programmatore può vedere una<br />
sola CPU (anche se il programma<br />
gira in parallelo sui vari PE)<br />
Il programmatore deve allocare<br />
manualmente il programma sui<br />
PE<br />
Necessario comunque<br />
prevedere primitive <strong>di</strong><br />
sincronizzazione<br />
Inefficienza dal punto <strong>di</strong> vista<br />
hardware<br />
Quasiasi informazione <strong>di</strong> stato<br />
deve essere con<strong>di</strong>visa tra i PE<br />
<br />
Moduli <strong>di</strong> interconnessione tra i PE<br />
più complessi<br />
<br />
Es. Out of order delivery<br />
<br />
Lo<strong>ad</strong> balancing<br />
Efficienza dal punto <strong>di</strong> vista<br />
hardware<br />
<br />
Interconnessione tra i PE più<br />
semplice (non c’è la necessità <strong>di</strong><br />
crossbar, che è complicata e<br />
richiede molto spazio sul chip)<br />
Ogni PE ha una parte del<br />
programma totale (instruction<br />
memory ridotta)<br />
<br />
Ogni PE deve mantenere l’intero<br />
programma nella sua memoria<br />
<br />
Le informazioni <strong>di</strong> stato possono<br />
essere mantenute locali al modulo<br />
(se non è richiesta la con<strong>di</strong>visione<br />
con gli altri moduli)<br />
24
Pool-based processing: moduli de<strong>di</strong>cati<br />
<br />
Inefficienza nel caso <strong>di</strong> interazione con<br />
moduli HW de<strong>di</strong>cati<br />
PE<br />
Ext. module<br />
<br />
La CPU va in stallo<br />
<br />
Aggiunta <strong>di</strong> supporto multithre<strong>ad</strong>ed al<br />
PE<br />
<br />
PE nettamente più complessi<br />
<br />
Programmazione più complessa<br />
T stallo<br />
<br />
<strong>Problematiche</strong> <strong>di</strong> sincronizzazione<br />
<br />
Necessità <strong>di</strong> conoscere i singoli tempi <strong>di</strong><br />
esecuzione per evitare lo stallo della CPU<br />
<br />
Ottimizzazione <strong>di</strong>fficile<br />
Una singola variazione dei tempi <strong>di</strong><br />
esecuzione (es. un modulo più veloce)<br />
scombina tutte le tempistiche<br />
precedentemente calcolate<br />
T<br />
25
Pool-based processing: lo<strong>ad</strong> balancing (1)<br />
Queue<br />
PE<br />
Queue<br />
Demux<br />
Queue<br />
Queue<br />
PE<br />
PE<br />
Mux<br />
Queue<br />
PE<br />
Parser<br />
Hash<br />
Lookup<br />
Table<br />
Lo<strong>ad</strong><br />
metrics<br />
26
Pool-based processing: lo<strong>ad</strong> balancing (2)<br />
<br />
<br />
<br />
Necessità <strong>di</strong> DEMUX/MUX per gestire il flusso dei<br />
pacchetti<br />
Bilanciamento su base sessione (più o meno)<br />
Assegnazione delle sessioni ai PE<br />
Fatta attraverso la lookup table<br />
<br />
<br />
<br />
Hit: si manda il pacchetto a quel PE<br />
Miss: si aggiunge una nuova entry e si sceglie il PE “migliore”<br />
tramite il blocco “lo<strong>ad</strong> metrics”<br />
Più sessioni possono “collidere” sulla stessa hit<br />
Necessità <strong>di</strong> cancellare vecchie sessioni<br />
<br />
<br />
TCP FIN/RST detection non è sempre accurato, oltre che costoso<br />
Problematica non banale<br />
27
Pool-based processing: lo<strong>ad</strong> balancing (3)<br />
<br />
Meccanismi <strong>di</strong> emergenza<br />
<br />
<br />
Sessioni grosse possono eccedere la capacità <strong>di</strong> un singolo NetPE<br />
<br />
<br />
Può essere anche il caso <strong>di</strong> una grossa sessione dati, con invio <strong>di</strong> molti<br />
pacchetti consecutivi<br />
Un singolo PE lavora, gli altri rimangono in stallo<br />
<br />
I pacchetti devono essere inoltrati in uscita con lo stesso or<strong>di</strong>ne dell’ingresso<br />
Il blocco “lo<strong>ad</strong> metrics” può ovviare a questo problema cambiando il<br />
comportamento del DEMUX<br />
<br />
<br />
<br />
“Reassignment”: la sessione viene spostata sul PE con la coda più breve (lo<br />
stato deve migrare dal vecchio al nuovo PE)<br />
“Spraying”: i pacchetti vengono reassegnati al PE con la coda più breve<br />
<br />
<br />
Altro…<br />
Le informazioni <strong>di</strong> stato devono essere mantenute in una memoria con<strong>di</strong>visa<br />
La memoria <strong>di</strong>venta un collo <strong>di</strong> bottiglia<br />
Conclusione: sistema estremamente complesso e poco<br />
scalabile<br />
<br />
Alla fine, l’unica soluzione è l’utilizzo <strong>di</strong> una memoria con<strong>di</strong>visa per<br />
mantenere lo stato<br />
28
Packet Processing: uso <strong>di</strong> core RISC<br />
<br />
Alcune caratteristiche dei RISC<br />
<br />
<br />
<br />
Possibilità <strong>di</strong> esecuzione <strong>di</strong> più istruzioni in parallelo<br />
<br />
Utile anche nel packet processing<br />
Processing limitato nel numero <strong>di</strong> dati<br />
<br />
<br />
<br />
Molte istruzioni su dati locali, mantenuti nei registri<br />
Bassa capacità <strong>di</strong> I/O<br />
<br />
Poco importante grazie alla out-of-order execution<br />
– possibile grazie al fatto che le istruzioni sono preponderanti sul numero <strong>di</strong> accessi a<br />
memoria<br />
Opposto a quanto necessario nel packet processing<br />
<br />
<br />
Accesso continuo ai pacchetti<br />
Continue elaborazioni basate su questi dati; relativamente poche istruzioni<br />
Processing ottimizzato su lunghi programmi (average time)<br />
<br />
Packet Processing: processing ottimizzato su programmi corti (maximum<br />
time)<br />
29
Data-flow processor (systolic processor)<br />
<br />
<br />
<br />
Modello data-driven<br />
Si crea una pipeline in cui ogni PE ha una singola istruzione<br />
<br />
<br />
<br />
<br />
L’istruzione è caricata a priori<br />
Esecuzione sincrona sui vari PE<br />
Il pacchetto si sposta da un PE all’altro<br />
Facile calcolare le <strong>prestazioni</strong><br />
<br />
Wire-speed se il programma ha un numero <strong>di</strong> istruzioni inferiore al numero<br />
<strong>di</strong> PE<br />
Modello <strong>di</strong> programmazione<br />
<br />
<br />
Una singola CPU con un numero massimo <strong>di</strong> istruzioni a <strong>di</strong>sposizione<br />
Modello molto semplice (è il classico Control Flow Model)<br />
PE PE PE PE PE<br />
Packet<br />
30
Data flow processor: esempio<br />
Coprocessori:<br />
- la comunicazione è fatta tramite<br />
un bus (o simile)<br />
- problematiche <strong>di</strong> conflitto/non<br />
determismo se questi sono con<strong>di</strong>visi<br />
sulla pipeline<br />
Implementazioni reali:<br />
- PE con più istruzioni in parallelo (VLIW)<br />
- PE con più istruzioni in sequenza<br />
31<br />
I blocchi <strong>di</strong> I/O servono per poter agganciare<br />
eventuali coprocessori esterni alla pipeline in<br />
base alle necessità del programma<br />
Le posizioni <strong>di</strong> “aggancio” devono essere<br />
stabilite a priori nel programma<br />
Source: Xecelerated Inc.
DFP: mantenere lo stato <strong>di</strong> esecuzione<br />
<br />
Il programma può avanzare in modo <strong>di</strong>namico<br />
<br />
<br />
Maggiore efficienza; le istruzioni sono schedulate <strong>di</strong>namicamente<br />
Complessità<br />
Non è possibile identificare un PE che faccia una funzione specifica (e<br />
quin<strong>di</strong> mantenere dello stato solamente al suo interno)<br />
<br />
<br />
<br />
<br />
Ogni PE deve avere l’intero programma in memoria<br />
Le interconnessioni verso i moduli esterni devono essere allocate<br />
<strong>di</strong>namicamente<br />
Si perde in pre<strong>di</strong>cibilità (determinismo)<br />
Possibilità <strong>di</strong> contese (non pre<strong>di</strong>cibili a priori) sulle risorse con<strong>di</strong>vise<br />
PE<br />
PE<br />
Packet<br />
Program Counter<br />
+ Flags<br />
32
DFP e branches<br />
<br />
Costrutti con<strong>di</strong>zionali: sono uno dei punti critici<br />
<br />
<br />
<br />
Ogni PE può essere configurato con più sequenze <strong>di</strong> esecuzione, attivabili<br />
<strong>di</strong>namicamente<br />
Un “contesto” può cambiare l’attuale sequenza <strong>di</strong> esecuzione<br />
“loop” classici sono comunque critici<br />
33
DFP e branches: esempio<br />
<br />
Mapping <strong>di</strong> un applicativo <strong>di</strong> forwar<strong>di</strong>ng <strong>di</strong> tipo DiffServ<br />
<br />
<br />
Si noti il ridotto numero <strong>di</strong> istruzioni (lo<strong>ad</strong>/store non sono necessarie)<br />
20 PE x 10 blocchi 200 PE elementari; fino a 64 contesti <strong>di</strong>versi<br />
NOP sequence<br />
34
Data-flow processor: modello <strong>di</strong><br />
programmazione<br />
<br />
<br />
<br />
Il C non è <strong>ad</strong>atto<br />
<br />
Mancano costrutti (es varie tipologie <strong>di</strong> memoria)<br />
Una proposta: modello Classify/Action<br />
<br />
introdotto da Agere<br />
Un campo ancora aperto (spesso si usa l’assembly)<br />
35