mory latency. Several combinations of these basic approaches can be made. For example, multiple parallel engines can be placed on each pipeline stage. So although the architecture itself is very important and some vendors go out of their way to tout the advantages their approach bestows to the contemplated applications, take a step back and look at the overall picture before becoming emotionally involved with a specific choice. SOFTWARE DEVELOPMENT ISSUES Network-processing vendors approach the issue of software development from different angles. Aside from the Net ASIC solutions, which essentially provide a fixed-functionality nonprogrammable solution, the rest of the platforms require some sort of programming. This programming can be straightforward, tedious, efficient, or painful for those who have to actually do the coding. Further compounding the problem, the programming model offered by a specific network-processor platform may facilitate or actually inhibit the efficient programming that has to occur. Some architectures are pipelined, multithreaded, or even sequential. One software-engineering solution cannot be expected to fit all possible requirements. In fact, the primary concern of mapping wire-speed-performance soft- ware functionality onto the available computing resources (the number of computing engines and of processing cycles) exists on all architectures. The issue then becomes how efficiently each of these varied architectures handles the tasks at hand. Let us look at the programming aspects of the problem. On one side of the spectrum, some ven- dors have been essentially preoccupied by the hardware prowess of their design and may have neg- lected and/or underestimated the need for superb software development tools to create and deliver wire-speed, feature-rich software. Text-based or graphical user interface (GUI)-based software devel- opment environments are available from different vendors trying to differentiate their offering. Other vendors propose a high-level language compiler, usually C,