Advanced Software Framework , Tools , and Languages for the IXP Family

The IXP network processor [1] architecture is designed to process packets at high rates where inter-arrival times between packets are sometimes less than the individual memory access latencies. To keep up with such high arrival rates, IXP presents a novel architecture consisting of a collection of multithreaded, multiprocessors with an explicit memory hierarchy. Such an architecture poses interesting challenges when an application developer wishes to develop software for a wide range of services that can easily be ported from one IXP processor to another. To make it easy to develop portable, modular software on IXPs, we currently provide a combination of development tools and a software framework consisting of libraries, run-time infrastructure, and APIs to facilitate the creation of application building blocks. This paper describes the future directions in IXP programming tools, software frameworks, languages, and compilers. We first identify the limitations of the current IXA software framework [3], describe extensions to remove such limitations and discuss how these extensions also help in the development process. Secondly, we provide an overview of the Developer Workbench tool suite and its features, which provide significant advancements over traditional development environments. We highlight features that enable architectural task modeling, allow debugging using bandwidth analysis, thread history, and operand tracing, and provide a novel packet-centric analysis based on extensible protocol packet generation, packet status, and a graphical view of the packet dataflow. And finally, to move the developers beyond a chip-centric view of programming, we also investigate domainspecific languages and adaptable run-time environments. We describe and justify one such research project under development, called Baker, to develop a domain-specific language for network processing. INTRODUCTION In this paper, we discuss three new ways that the software development infrastructure for programming network processors is being improved: the existing IXA software framework is being extended, new features are being added to the Developer Workbench, and research in developing a domain-specific language and compiler for packet processing is being pursued. We start with a brief introduction to each topic. Framework Extensions Firstly, network processors are being targeted at a wide range of applications with varying packet-processing and throughput requirements. The programmability and flexibility of a network processor make it suitable for applications ranging from Voice over IP to content-based routing with data rates spanning OC-3 to OC-192. In such an environment, the investment made in software development by equipment manufacturers is increasingly significant. Preserving this investment and leveraging it across multiple projects are key considerations when choosing a network processor. The IXA software framework [3] provides the necessary software infrastructure to help develop modular, reusable software building blocks for network processors of the IXP family. The IXA Portability Framework is now widely adopted for software development on the IXP family. However, the framework is unable to fully support some classes of applications. These applications require support for specific features such as multicast forwarding, handling packet fragmentation, and running at low rates (OC-3 to OC-12). The IXA framework, therefore, must be extended so that it can support all applications efficiently and easily. The main shortcomings of the existing software framework are (i) lack of support for the creation of multiple packets from a packet in the packet processing stage, (ii) lack of support for efficient manipulation of Intel Technology Journal, Volume 7, Issue 4, 2003 Advanced Software Framework, Tools, and Languages for the IXP Family 65 packet data buffers when they are sent to multiple interfaces, and (iii) the inability of microblocks that were built independently to fit together when run on different (not the same) threads within a microengine.