TABLE OF CONTENTS Now that you have read all about using multiple threads to process packets, let s apply this knowledge to the receive and transmit tasks. In Chapter 5, we developed single-threaded receive and transmit drivers that, while functionally correct, won t likely be as fast as they could be. So, multithreaded versions of receive and transmit drivers represent an excellent example of how to apply the multithreaded programming techniques discussed in previous chapters and boost performance of the sample code. Besides, it just does not seem right to have the other threads of the receive and transmit microengines doing nothing.
Writing multithreaded receive and transmit drivers is also valuable for another reason: it illustrates some of the subtle ordering issues when performing receive and transmit tasks on multiple threads. By covering these tasks in this chapter, we can hopefully eliminate some common logic errors in multithreaded receive and transmit code.
Chapters 2 and 5 described the process of receiving a packet on the IXP2XXX processor. Recall that the basic challenge is the reassembly of multiple mpackets into one packet. The code in Chapter 5 performs this reassembly but ignores the issues of mpacket and packet ordering, as well as sharing the reassembly state between the threads of the microengine. The single-threaded nature of the code in Chapter 5 guarantees these ordering constraints are met without any explicit ordering constructs and makes state sharing between threads unnecessary. To make a multithreaded receive driver, both issues must be addressed.
