1 / 30

IP Lookup Arvind Computer Science & Artificial Intelligence Lab

IP Lookup Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology. Line Card (LC). Arbitration. Packet Processor. Control Processor. SRAM (lookup table). Switch. Queue Manager. IP Lookup. Exit functions. LC. LC. LC.

rafael-duke
Download Presentation

IP Lookup Arvind Computer Science & Artificial Intelligence Lab

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IP Lookup Arvind Computer Science & Artificial Intelligence Lab Massachusetts Institute of Technology http://csg.csail.mit.edu/arvind

  2. Line Card (LC) Arbitration Packet Processor Control Processor SRAM (lookup table) Switch Queue Manager IP Lookup Exit functions LC LC LC IP Lookup block in a router • A packet is routed based on the “Longest Prefix Match” (LPM) of it’s IP address with entries in a routing table • Line rate and the order of arrival must be maintained line rate  15Mpps for 10GE http://csg.csail.mit.edu/arvind

  3. 7.14.*.* A 7 B … … … … … … … … … … … … … … … A A C A C A F F F F F F F F F 7.14.7.3 B 10.18.200.* C 10.18.200.5 D 5.*.*.* E * F 5 D A 4 Sparse tree representation 0 14 3 5 E F 7 10 18 255 200 2 3 In this lecture: Level 1: 16 bits Level 2: 8 bits Level 3: 8 bits  1 to 3 memory accesses 1 4 http://csg.csail.mit.edu/arvind

  4. 0 0 0 … … … 28 -1 28 -1 … 216 -1 “C” version of LPM int lpm (IPA ipa) /* 3 memory lookups */ { int p; /* Level 1: 16 bits */ p = RAM [ipa[31:16]]; if (isLeaf(p)) return value(p); /* Level 2: 8 bits */ p = RAM [ptr(p) + ipa [15:8]]; if (isLeaf(p)) return value(p); /* Level 3: 8 bits */ p = RAM [ptr(p) + ipa [7:0]]; return value(p); /* must be a leaf */ } Not obvious from the C code how to deal with - memory latency - pipelining Memory latency ~30ns to 40ns Must process a packet every 1/15 ms or 67 ns Must sustain 3 memory dependent lookups in 67 ns http://csg.csail.mit.edu/arvind

  5. Rigid pipeline Linear pipeline Inefficient memory usage but simple design Efficient memory usage through memory port replicator 1 2 3 Longest Prefix Match for IP lookup:3 possible implementation architectures Circular pipeline Efficient memory with most complex control Designer’s Ranking: Which is “best”? http://csg.csail.mit.edu/arvind Arvind, Nikhil, Rosenband & Dave ICCAD 2004

  6. outQ inQ yes enter? done? RAM no fifo Circular pipeline The fifo holds the request while the memory access is in progress The architecture has been simplified for the sake of the lecture. Otherwise, a “completion buffer” has to be added at the exit to make sure that packets leave in order. http://csg.csail.mit.edu/arvind

  7. n FIFO interface FIFO#(type t); method Action enq(t x); // enqueue an item method Action deq(); // remove oldest entry method t first(); // inspect oldest item endinterface enab enq rdy not full n = # of bits needed to represent a value of type t enab FIFO module rdy deq not empty n first rdy not empty http://csg.csail.mit.edu/arvind

  8. ctr++ Ready (ctr > 0) Ack ctr deq deq enq Enable Data Ready Synch Mem Latency N req ctr-- peek Data Addr Request-Response Interface for Synchronous Memory interface Mem#(type addrT, type dataT); method Action req(addrT x); method Action deq(); method dataT peek(); endinterface Making a synchronous component latency- insensitive http://csg.csail.mit.edu/arvind

  9. inQ enter? done? RAM fifo Circular Pipeline Code rule enter (True); IP ip = inQ.first(); ram.req(ip[31:16]); fifo.enq(ip[15:0]); inQ.deq(); endrule done? Is the same as isLeaf rule recirculate (True); TableEntry p = ram.peek(); ram.deq(); IP rip = fifo.first(); if (isLeaf(p)) outQ.enq(p); else begin fifo.enq(rip << 8); ram.req(p + rip[15:8]); end fifo.deq(); endrule When can enter fire? inQ has an element and ram & fifo each has space http://csg.csail.mit.edu/arvind

  10. inQ enter? done? RAM fifo Circular Pipeline Code: discussion rule enter (True); IP ip = inQ.first(); ram.req(ip[31:16]); fifo.enq(ip[15:0]); inQ.deq(); endrule rule recirculate (True); TableEntry p = ram.peek(); ram.deq(); IP rip = fifo.first(); if (isLeaf(p)) outQ.enq(p); else begin fifo.enq(rip << 8); ram.req(p + rip[15:8]); end fifo.deq(); endrule When can recirculate fire? ram & fifo each has an element and ram, fifo & outQ each has space Is this possible? http://csg.csail.mit.edu/arvind

  11. n enab enq rdy not full enab rdy deq not empty FIFO module One Element FIFO enq and deqcannot even be enabled together much less fire concurrently! module mkFIFO1 (FIFO#(t)); Reg#(t) data <- mkRegU(); Reg#(Bool) full <- mkReg(False); method Action enq(t x) if (!full); full <= True; data <= x; endmethod method Action deq() if (full); full <= False; endmethod method t first() if (full); return (data); endmethod method Action clear(); full <= False; endmethod endmodule The functionality we want is as if deq “happens” before enq; if deq does not happen then enq behaves normally We can build such a FIFO more on this later http://csg.csail.mit.edu/arvind

  12. inQ enter? done? RAM fifo Dead cycles rule enter (True); IP ip = inQ.first(); ram.req(ip[31:16]); fifo.enq(ip[15:0]); inQ.deq(); endrule assume simultaneous enq & deq is allowed rule recirculate (True); TableEntry p = ram.peek(); ram.deq(); IP rip = fifo.first(); if (isLeaf(p)) outQ.enq(p); else begin fifo.enq(rip << 8); ram.req(p + rip[15:8]); end fifo.deq(); endrule Can a new request enter the system when an old one is leaving? Is this worth worrying about? http://csg.csail.mit.edu/arvind

  13. yes in enter done? RAM no fifo The Effect of Dead Cycles Circular Pipeline • RAM takes several cycles to respond to a request • Each IP request generates 1-3 RAM requests • FIFO entries hold base pointer for next lookup and unprocessed part of the IP address What is the performance loss if “exit” and “enter” don’t ever happen in the same cycle? >33% slowdown! Unacceptable http://csg.csail.mit.edu/arvind

  14. yes yes The compiler issue • Can the compiler detect all the conflicting conditions? • Important for correctness • Does the compiler detect conflicts that do not exist in reality? • False positives lower the performance • The main reason is that sometimes the compiler cannot detect under what conditions the two rules are mutually exclusive or conflict free • What can the user specify easily? • Rule priorities to resolve nondeterministic choice In many situations the correctness of the design is not enough; the design is not done unless the performance goals are met http://csg.csail.mit.edu/arvind

  15. Scheduling conflicting rules • When two rules conflict on a shared resource, they cannot both execute in the same clock • The compiler produces logic that ensures that, when both rules are applicable, only one will fire • Which one? source annotations (* descending_urgency = “recirculate, enter” *) http://csg.csail.mit.edu/arvind

  16. inQ enter? done? RAM fifo So is there a dead cycle? rule enter (True); IP ip = inQ.first(); ram.req(ip[31:16]); fifo.enq(ip[15:0]); inQ.deq(); endrule rule recirculate (True); TableEntry p = ram.peek(); ram.deq(); IP rip = fifo.first(); if (isLeaf(p)) outQ.enq(p); else begin fifo.enq(rip << 8); ram.req(p + rip[15:8]); end fifo.deq(); endrule In general these two rules conflict but when isLeaf(p) is true there is no apparent conflict! http://csg.csail.mit.edu/arvind

  17. Rule Spliting rule fooT (p); r1 <= 5; endrule rule fooF (!p); r2 <= 7; endrule rule foo (True); if (p) r1 <= 5; else r2 <= 7; endrule  rule fooT and fooF can be scheduled independently with some other rule http://csg.csail.mit.edu/arvind

  18. Spliting the recirculate rule rule recirculate (!isLeaf(ram.peek())); IP rip = fifo.first(); fifo.enq(rip << 8); ram.req(ram.peek() + rip[15:8]); fifo.deq(); ram.deq(); endrule rule exit (isLeaf(ram.peek())); outQ.enq(ram.peek()); fifo.deq(); ram.deq(); endrule rule enter (True); IP ip = inQ.first(); ram.req(ip[31:16]); fifo.enq(ip[15:0]); inQ.deq(); endrule Now rules enter and exit can be scheduled simultaneously, assuming fifo.enq and fifo.deq can be done simultaneously http://csg.csail.mit.edu/arvind

  19. n enab enq rdy not full enab rdy deq not empty FIFO module Back to the fifo problem module mkFIFO1 (FIFO#(t)); Reg#(t) data <- mkRegU(); Reg#(Bool) full <- mkReg(False); method Action enq(t x) if (!full); full <= True; data <= x; endmethod method Action deq() if (full); full <= False; endmethod method t first() if (full); return (data); endmethod method Action clear(); full <= False; endmethod endmodule The functionality we want is as if deq “happens” before enq; if deq does not happen then enq behaves normally http://csg.csail.mit.edu/arvind

  20. RWire to rescue interface RWire#(type t); method Action wset(t x); method Maybe#(t) wget(); endinterface Like a register in that you can read and write it but unlike a register - read happens after write - data disappears in the next cycle RWires can break the atomicity of a rule if not used properly http://csg.csail.mit.edu/arvind

  21. enab enq rdy not full enab rdy deq not empty FIFO module One Element “Loopy” FIFO module mkLFIFO1 (FIFO#(t)); Reg#(t) data <- mkRegU(); Reg#(Bool) full <- mkReg(False); RWire#(void) deqEN <- mkRWire(); method Action enq(t x) if (!full || isValid (deqEN.wget())); full <= True; data <= x; endmethod method Action deq() if (full); full <= False; deqEN.wset(?); endmethod method t first() if (full); return (data); endmethod method Action clear(); full <= False; endmethod endmodule This works correctly in both cases (fifo full and fifo empty). !full or http://csg.csail.mit.edu/arvind

  22. Problem solved! LFIFO fifo <- mkLFIFO; // use a loopy fifo • RWire has been safely encapsulated inside the Loopy FIFO – users of Loopy fifo need not be aware of RWires rule recirculate (True); TableEntry p = ram.peek(); ram.deq(); IP rip = fifo.first(); if (isLeaf(p)) outQ.enq(p); else begin fifo.enq(rip << 8); ram.req(p + rip[15:8]); end fifo.deq(); endrule http://csg.csail.mit.edu/arvind

  23. outQ inQ Packaging a module:Turning a rule into a method enter? done? RAM fifo rule enter (True); IP ip = inQ.first(); ram.req(ip[31:16]); fifo.enq(p[15:0]); inQ.deq(); endrule method Action enter (IP ip); ram.req(ip[31:16]); fifo.enq(ip[15:0]); endmethod Similarly a method can be written to extract elements from the outQ http://csg.csail.mit.edu/arvind

  24. remainingIP Circular pipeline with Completion Buffer getToken luResp cbuf yes inQ enter? luReq done? RAM no fifo Completion buffer - gives out tokens to control the entry into the circular pipeline - ensures that departures take place in order even if lookups complete out-of-order The fifo holds the token while the memory access is in progress: Tuple2#(Bit#(16), Token) http://csg.csail.mit.edu/arvind

  25. cbuf inQ enter? done? RAM fifo Circular Pipeline Codewith Completion Buffer rule enter (True); Token tok <- cbuf.getToken(); IP ip = inQ.first(); ram.req(ip[31:16]); fifo.enq(tuple2(ip[15:0], tok)); inQ.deq(); endrule rule recirculate (True); TableEntry p <- ram.resp(); match {.rip, .tok} = fifo.first(); if (isLeaf(p)) cbuf.put(tok, p); else begin fifo.enq(tuple2(rip << 8, tok)); ram.req(p+rip[15:8]); end fifo.deq(); endrule http://csg.csail.mit.edu/arvind

  26. I I V I V I i o cnt buf Elements must be representable as bits Completion buffer interface CBuffer#(type t); methodActionValue#(Token) getToken(); methodAction put(Token tok, t d); methodActionValue#(t) getResult(); endinterface typedef Bit#(TLog#(n)) TokenN#(numeric type n); typedef TokenN#(16) Token; module mkCBuffer (CBuffer#(t)) provisos (Bits#(t,sz)); RegFile#(Token, Maybe#(t)) buf <- mkRegFileFull(); Reg#(Token) i <- mkReg(0); //input index Reg#(Token) o <- mkReg(0); //output index Reg#(Int#(32)) cnt <- mkReg(0); //number of filled slots … http://csg.csail.mit.edu/arvind

  27. I I V I V I i o cnt buf Completion buffer // state elements // buf, i, o, n ... methodActionValue#(t) getToken() if (cnt < maxToken); cnt <= cnt + 1; i <= i + 1; buf.upd(i, Invalid); return i; endmethod methodAction put(Token tok, t data); return buf.upd(tok, Valid data); endmethod methodActionValue#(t) getResult() if (cnt > 0) &&& (buf.sub(o) matches tagged (Valid .x)); o <= o + 1; cnt <= cnt - 1; return x; endmethod Home work: Think about concurrency Issues, i.e., can these methods be executed concurrently? Do they need to? http://csg.csail.mit.edu/arvind

  28. Rigid pipeline Linear pipeline Inefficient memory usage but simple design Efficient memory usage through memory port replicator Longest Prefix Match for IP lookup:3 possible implementation architectures Circular pipeline Efficient memory with most complex control Which is “best”? http://csg.csail.mit.edu/arvind Arvind, Nikhil, Rosenband & Dave ICCAD 2004

  29. IP addr Replicated: BEST: MUX result IP addr MUX / De-MUX result FSM FSM FSM FSM FSM Counter MUX / De-MUX RAM RAM Implementations of Static pipelines Two designers, two results Each packet is processed by one FSM Shared FSM http://csg.csail.mit.edu/arvind

  30. Synthesis results Synthesis: TSMC 0.18 µm lib - Bluespec results can match carefully coded Verilog - Micro-architecture has a dramatic impact on performance - Architecture differences are much more important than language differences in determining QoR http://csg.csail.mit.edu/arvind V = Verilog;BSV = Bluespec System Verilog

More Related