U. Glaeser

The above analysis demonstrates that in all three cases, new architecture-level and circuit-level innovations
are required to develop a network processor that meets the OC-768 performance goal.
Two basic approaches to speeding up network packet processing inside a network processor are
pipelining and parallelization. A deeper pipeline reduces the cycle time of the pipeline and, therefore,
improves the system throughput. However, because packet classification, packet forwarding, and packet
scheduling each exhibit complicated internal dependencies and sometimes iterative structures, it is
difficult to pipeline these functions effectively. Parallelization can be applied at different granularities.
Finer granularity parallelism is more difficult to exploit but potentially leads to higher performance gain.
In the case of network packet processing, because processing of one packet is independent of processing
of another packet, packet-level parallelism appears to be the right granularity that strikes a good balance
between performance gain and implementation complexity. Typically, a thread is dedicated to the processing
of one packet, and different threads can run in parallel on distinct hardware engines. To reap
further performance improvement by exploiting instruction-level parallelism, researchers and companies
have proposed to run concurrent packet-processing threads on a simultaneous multi-threading processor
[5,11] to mask as many pipeline stalls as possible. Such multithreading processors require the support
of multiple hardware contexts and fast context switching.
Compared with generic CPU workloads, network packet processing requires much more frequent bitlevel
manipulation, such as header field extraction and header checksum computation. In a standard
RISC processor, extracting an arbitrary range of bits from a 32-bit word requires at least three instructions,
and performing a byte-wide summing of the four bytes within a word takes at least 13 instructions.
Therefore, commercial network processors [6] include special bit-level manipulation and 1’s complement
instructions to speed up header field extraction and replacement, as well as packet checksumming
computation.
Caching is arguably the most effective and most often used technique in modern computer system
design. One place in network processor design to which caching can be effectively applied is packet
classification. Since multiple packets travel on a network connection in its lifetime, in theory each
intermediate network device only needs to perform packet classification once for the first packet and
reuses the resulting classification decision for all subsequent packets. This corresponds to temporal locality
if one treats the set of all possible values of the header fields used in packet classification as an address
space. Empirical studies [7,8] show that network packet streams indeed exhibit substantial temporal
locality but very little spatial locality. In addition, unlike CPU cache, the classification results for neighboring
points in this address space tend to be identical. Therefore, network processor cache can be designed
to cache address ranges rather than just address space points, as in standard cache. Chiueh and Pradhan [8]
showed that caching ranges of classification address space can increase the effective coverage of a network
processor cache by several orders of magnitude as compared to conventional caches that cache individual
addresses.
Another alternative to speed up packet classification is through special content-addressable memory
(CAM) [13]. Commercial CAMs support ternary comparison logic (0, 1, and X or don’t-care). Classification
rules are pre-stored in the CAMs. Given an input packet, the selective portion of its packet header
is compared against all the stored classification patterns in parallel, and a priority decoder picks the
highest priority among the matched rules if there are multiple of them. Although CAM can identify
relevant packet classification rules at wire speed, two problems are associated with applying CAM to the
packet classification problem. First, to support range match, e.g., source port number 130–202, one has
to break a range rule to multiple range rules, each covering a range whose size is a multiple of 2. This is
because CAMs only support don’t-care match but not arbitrary arithmetic comparison. For example,
the range 129–200 needs to be broken down into eight ranges: 130–130, 131–132, 133–136, 137–144,
145–160, 161–192, 193–200, and 201–202. For classification rules with multiple range fields, the need
for range decomposition can significantly increase the number of CAM entries required. Second, because
CAMs are hardwired memory with built-in width, it cannot easily support matching of variable-length
fields such as URL, or accommodate changing packet classification rules after network devices are put
into field use.
© 2002 by CRC Press LLC