EETimes

Embedded Systems November 2000 Vol13_12

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

Contents of this Issue

Navigation

Page 57 of 189

For multi-core network processors and multi-threaded cores, an important question is: who handles scheduling? be processed by which core? In some network processors, this is determined by the hardware. In others, the soft- ware determines Depending on you r application and algorithms, Physical Interface the answe r. the ability to control which packets go to which cores may be an important requirement. For oth- ers, the speed of hardware scheduling may be essential. Configuration Bus 8-bit POS-PHY 8-bit POS-PHY PCI to Host CPU dependencies, a web switch can still benefit from parallelism. How? If the packets are sorted so that packets fo r a particular connection always go to the arne RISC core, then packets for that connection will be proces ed in order, and in terpacket dependencies will have been observed. If you are evaluating a network processor, you should carefully consid- er what kind of interpacket dependen- cies you have, and how each network processor handles them. Network proce sor designed for very high peed traffic often have no provision for interpacket dependencies and thus would not be appropriate for net- work devices doing application-level processing. Speeds and feeds As indicated above, a wide variety of network processor designs exist. One rea on fo r this is that the interface speeds fo r ne twork devices range over several orders of magnitude. Table 1 lists the maximum processing time a network device may use if it wants to perform at wire-speed fo r various interfaces. The rightmost col- umn can be considered a per-packe t time budget. From reading the marketing litera- ture of network processor vendors, you might believe that all network processors are designed for gigabit speeds, and the faste r the be tter. However, depending on your applica- tion, a lower network proce or might be a better choice. Network processors designed fo r the fastest speeds are much more I/ 0 driven, and have less capabilities for pattern matching, sort- ing out in terpacket dependencies, and other features desirable fo r applica- tion-level processing. Multiprocessing and multithreading Many network processors include mul- tiple processor cores th at run in paral- lel. Some of the cores, notably those in Intel's IXP1200 and Sitera's Prism net- work processors, include hardware support for multiple contexts, which essentially results in zero context- switch time between threads on the same core. For multi-core network processors and multi-threaded cores, an impor- tant question is: who handles schedul- ing? Consider Figure 3, where six packets are destined for our four-core network processors. Which packet will 56 NOVEMBER 2000 Embedded Systems Programming Market gossip The hot news in the network proces- sor market has been acquisitions and standards. Between September 1999 and June 2000, major semiconductor manufacture rs went on a buying spree, each acquiring a network processor or acceleration company. During that time, Intel acquired NetBoost, Conexant acquired Maker, Lucent acquired Agere, Motorola acquired C-Port, and Vitesse acquired Sitera. On the standards front, compa- nies in the switch fabric and network processor business have formed two standards bodi es. The Common Switch Interface Consortium (CSIX) was formed to standardize a hard- ware interface between switch fabric chips and proce sing chips. The Commo n Programming Inte rface Forum (CPIX) was formed to stan- dardize software interfaces for net- work processors. These two groups include in their membership almost every company that has anything to do with ne twork processing, except Intel. In particular, the aims of CPIX are inte resting: develop software stan- dards for network processors, so that network processor software is portable to different network proces- sors. While this would be benefi cial to many network equipment manufac- ture rs, vastly different network processor architectures make tha t prospect unlikely, at least without large performance sacrifices. Un til CPIX releases its standard, it looks more like an anti-Intel coalition than a standards body.

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems November 2000 Vol13_12