Various alternatives have been employed for high-performance networking and packet processing. Traditionally, ASICs have been used for the highest-level requirements. But their significant expense, expanded time-to-market (TTM), increased risk, and inflexibility often outweigh their speed and high-volume cost benefits. At the other end of the spectrum, general-purpose processors provide significant cost, flexibility, and TTM benefits but can't handle applications needing gigabit-class performance. Specialized merchant silicon splits the difference but is often limited in function and doesn't allow for sufficient end-product differentiation. Also, merchant silicon markets are often too small to support attractive pricing.
Network processors (NPs) were created to solve this problem, offering the promise of ASIC-class performance with general-purpose processor programmability, flexibility, and compatible scalability.
Unfortunately, while the current set of available NPs offers sufficient performance and programmability, their programming models are extremely complex, requiring detailed knowledge of the underlying NP—far more than what is required in traditional embedded real-time programming. Dealing with advanced and complex architectural issues—like multiple parallel processors and threaded processor models, multiple classes of memory (each with different interfaces), large and specialized register models, unique hardware acceleration units, and sophisticated synchronization mechanisms—quickly reduces the value of traditional high-level languages (such as C) to just a hair above assembly-level programming.
The impact of this complexity is substantial. The most obvious is increased software development and lifecycle maintenance costs due to the steep learning curve and long development, debug, and test phases. There are other drawbacks, too. For example, often a functional prototype is not available until late in the project cycle, delaying integration with other system components and delaying overall system performance modeling. Another artifact of the high software complexity is that designers often hesitate to modify or enhance working designs due to the high risk of change and lengthy debug cycle. This negates one of the strongest benefits of NP-based designs: flexibility.
The solution to managing this complexity is abstraction—specifically, to abstract the underlying NP hardware by creating an application-specific programming model implemented as a virtual machine (VM). Implementing a VM in software atop the NP provides the programmer with an architecture-independent environment that offers the obvious potential to be completely portable and scalable. But there are other significant benefits, such as offering superior robustness by building in logic to perform bounds checking, null pointer/handle checking, and other exception handling. Lastly, a VM approach allows for advanced capabilities such as dynamic compilation that can improve application power and flexibility and enable new classes of applications.
Of course, there is no such thing as a free lunch. Abstraction can come at a price, most often a real or perceived performance penalty when compared to ideal performance. To minimize performance impacts, focusing VM implementations on an application-specific domain (e.g., packet processing) is beneficial. By focusing on a particular application area, the VM implementation can be constructed with highly optimized, best-of-breed algorithms and state machines used in that domain.
Hand-tuned implementations that are optimized to specific processing and data flow characteristics (e.g., requiring pipelining and parallelism), developed by experts focused on the domain, will often outperform those written by general NP application designers. Finally, one could argue that the final system performance will be greater when all components of the system are available as early in the product cycle as possible, allowing more time to analyze and optimize in real-world conditions.
The network-processor system complexity crisis is very real and needs to be addressed, and a proven approach is to do this via abstraction. Using this approach (an application-specific programming model implemented as a VM) enables application developers to focus their attention on packet-processing logic and not on the underlying NP architecture—reversing the current industry trend.
Reprints
