TABLE OF CONTENTS In Chapter 7, we wrote code under the assumption that the code must be able to run on any number of microengines. This assumption is appropriate for most processing code, like that of Chapter 7, which exhibits high degrees of packet-level parallelism. However, what if one of the functions in your application does not exhibit this characteristic? For such functions, you might wonder whether it is better to remove the assumption that the code is executing on multiple microengines, and the answer is: quite possibly!
Consider what would happen if you could assume that your microblock was only going to run on one thread, or more realistically, one microengine. Synchronization across the threads would become trivial and fast through the use of absolute GPRs and local memory. In addition, other assumptions regarding microengine resource availability, for example use of the CAM, could be made. Writing code under this singlemicroengine assumption is called a context pipeline stage.
Of course, context pipeline stages have their own set of restrictions, such as limited numbers of threads and strict performance guarantees because no other microengine can share the workload. We explore both the benefits and consequences of context pipeline stages in this chapter through an example of packet scheduling. And, as a bonus, implementing a packet scheduler nicely completes our example code!
The packet-processing code in the previous two chapters classifies packets into flows and then performs congestion avoidance on those flows. While all of this processing exposes many features...
