EETimes

Embedded Systems November 2000 Vol13_12

Issue link: http://dc.ee.ubm-us.com/i/71849

Contents of this Issue

Navigation

Page 49 of 189

The different requirements of data plane and control plane tasks are often addressed by what is called a fast path-slow path design. CPU. This archi tecture is parti cular- ly strong because it allows you to implement simple tim e-criti cal algo- rithms in hardware and complex algorithms in software. Now that we have a handle on net- work processing requirements, let's start looking at network processors. plane tasks require little processing power, but a large amount of code. Using a router as an example, this phenomenon can be considered from two van tages, code size or processing requiremen ts. The data plane tasks of a router were described briefly in the previous section, and a detail ed description would no t be much longer. It seems apparent that one could handle the data plane tasks with- out a lot of code. The control plane tasks were also described, but the description was not nearly as precise. Even in a traditional network device like a router, control task implemen tations vary. All routers will have code to handle routing pro- tocols like OSPF and BGP, and they will almost certainly have a serial port for configuration. But they may be managed via a web browser, Java appli- cation, SNMP, or all three. This can add up to a lot of code. If you' re still not convinced, look at the size of Cisco's books on how to configure its routers. Now, let's conside r the packe ts entering the route r. Nearly all of th em a re addressed to somewhe re else, and need to be examined and fo rwarded the re ve ry qui ckly. For example, for a router to run wire- speed with a 155Mbps OC-3 link, it needs to forward a 64-byte packe t in three microseconds. These packets may not need to have much done with th em, but it needs to be done in a tim ely manne r. This requires tight code and a lot of processing power. By contras t, the occasional OSPF packe t that causes the ro uting tables to be upda ted, or an HTTP request to make a conf igura ti o n change might require a fair bit of code to be handled properl y, but will have little impact on ove rall pro- cessing requirements. Fast path, slow path The diffe rent requirements of data plane and control plane tasks a re often addressed by what is called a f ast path-slow path design. In thi s type of design , as packets e nter the ne t- working device, their d estina tion address and port are examined, and based on that examina ti on, th ey are sent on eithe r the "slow pa th " or the "fas t pa th" intern all y. Packets that need minimal or normal processing take the fast path , and packe ts tha t need unusual or complex processing take the slow path. Fast path packe ts correspond to da ta plane tasks, while slow path packe ts correspond to con- trol pl ane tasks. Once th ey have been processed, packets from both the slow and fas t path may leave via th e same ne two rk interface. See Figure 1. Dividing up the processing in this way provides substa ntial impleme nta tion flexibili ty. While the slow path processing will almost cer- tainly be implemented with a CPU, fas t path processing can be imple- mented with an FPGA, ASIC, co- processor, or maybe just anoth e r 48 NOVEMBER 2ooo Embedded Systems Programming ASICs, the original network processors Over the last 10 years, demand for higher bandwidth networks has driven the evolution of network equipment design. The first designs used CPUs exclusively. However, general purpose CPUs are not ideal for network pro- gramming. While their programmabil- ity is important, their floating-point units go unused, they have too much data cache, and too little memory bandwidth. Further, demand for band- width is increasing faster than CPU speeds. Network equipment designers cannot afford to wait for tl1e next gen- eration of CPUs to increase the speed of tl1eir devices. Even witl1 fast path- slow path designs, problems still arise. For example, how do you make the fast path fast enough? The conventional answe r is to design an ASIC. Well-designed ASICs can be much faster than CPUs, but they are difficult and expensive to develop; tl1e cost of the tools alone make them unaffordable for many companies. Moreover, ASICs usually have limited programmability and must be redesigned as protocols and interfaces change. Network processor compa nies hope to bridge the divide between ASICs and CPUs by providing a device that is as programmable as a CPU but as fas t as an ASIC. Network processor architectures Network processor architectures make CPU architectures look staid and bor- ing. Network processor designers from diffe rent companies have made vastly different decisions about I/0 in ter- faces, memory interfaces, and pro-

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems November 2000 Vol13_12