ing. The compiler and debugger are solid and GNU based, offer- ing both performance and code-size optimization capabilities. The big picture of the development environment is completed with performance-analysis and traffic-scripting tools. To interface the main network application with specialized network-processing code, which han- dles data parsing, classification and table management, traffic management, data modification, con- trol plane management, and buffer management, independent of whether the functions occur at forwarding or control planes, a series of APIs provide the peace of mind associated with code com- patibility and the preservation of investment. Figures 8.4 and 8.6 illustrate this point. These APIs, which act in a similar way as APIs found in the traditional computing world, abstract the underlying hardware architecture of the C-5e network processor and its associated Q-5 TMC. They offer support for the most common among network task- building blocks, such as physical interface management, data forwarding, table lookups, buffer man- agement, and queuing operations. Writing code that interfaces with these APIs is a good way to ensure software compatibility and scalability from generation to generation of Motorola's C-Port family of network processors. More specifically, in terms of QoS requirements, the combination of Motorola's APIs and stan- dard C language is more than enough to configure the Q-5 TMC to perform its QoS-related tasks along with a main application, which runs on the C-5 or C-5e network processor itself. The APIs allow the coding of software that implements the QoS service from as low as the physical-level functions all the way to host-based supervisory and billing functions. If the Q-5 TMC is used independently of Motorola's network processors as a stand-alone traffic manager, the same APIs enable the correct con- figuration of the chip. Downloaded from Digital Engineering Library McGraw-Hill (www.digitalengineeringlibrary.com) Copyright © 2004 The McGraw-Hill Companies. All ri