The types and number of networking protocols available is proliferating at a rapid rate, and many existing protocols are being upgraded to faster, more complex, and/or more efficient versions. Example of packet protocols which may be nested may include, but are not limited to Transport Control Protocol (TCP), Internet Protocol (IP, IPv4, IPv6), User Datagram Protocol (UDP), Ethernet (802.3), Wi-Fi (IEEE 802.11), WiMAX (IEEE 802.16), and ZigBee (IEEE 802.15.4).
Networking applications are built as a succession of layers with each layer based on a different protocol. For example, FIG. 1 illustrates a data packet 100 having multiple levels of networking protocols. A typical data packet, such as data packet 100, may include a first level 110 having a base protocol that may include a header 112, a payload 114, and an error detection code 116 (e.g., a checksum). The header 112 may include a number of fields of varying sizes, which provide information about the data packet 100 including, for example, the size/length, the source address, and the destination address. The payload 114 of the first level 110 may also be a variable size. The payload 114 of the first level 110 may include a header 122 and payload 124 (and possibly an error detection code) of a second (nested) level protocol 120. Similarly, the payload 124 of the second level 120 may include a header 132 and a payload 134 (and possibly an error detection code) of a third (nested) level protocol 130.
This nesting of packet data in multiple levels of protocol (i.e., nesting of packets in payloads) may repeat for several layers. The nesting of protocols can make it difficult to locate and/or isolate a particular piece of data in a packet, because locating and isolating a particular piece of data in a packet is based on the base protocol and all prior nested protocols. The difficulty is compounded when locating/isolating a particular piece of data in substantially real-time is desirable. The difficulty can affect performance of applications using particular packet data. As an example, computer networking involves analyzing packet headers to verify protocol correctness, extraction of protocol header fields, and making decisions based on the protocol header fields. Routing decisions—e.g., how to route a packet—are based on, for example, a destination address field. The efficiency with which header fields can be extracted, such as the destination address field of a network packet, may be a significant factor in the performance of a network and packet-based applications.
Generally, packet processing solutions use either a specific hardware solution for a specific networking protocol, or standard processor based solutions with the protocol processing written in software. The specific hardware solutions are used for processing speed, but lack flexibility. They typically support a specific protocol or protocols, can be difficult to extend, and can require a longer development time.
Standard processor solutions can provide substantial flexibility by allowing changes to the protocol supported by the changing of the software program. There are, however, drawbacks to standard processor solutions. Packet processing in a microprocessor is typically implemented with a succession of mask and shift instructions to extract protocol fields from the received data.
To be used by standard processor solutions, the packet data must be made available to the arithmetic logic unit (ALU) portion of the processor. A standard processor typically has to perform an uncached read to load packet data. For example, the ALU executes a MOV instruction (uncached read cycle) to read the packet data from memory to the processor register space. Once the data is in the processor register space, the data may then be manipulated at the processor instruction cycle rate. The MOV instruction, however, may be a significant bottleneck, which can significantly diminish performance, particularly with modern highly pipelined processors where it can cause a stall of the pipelined data.