|Publication number||US7441179 B2|
|Application number||US 10/692,585|
|Publication date||Oct 21, 2008|
|Filing date||Oct 23, 2003|
|Priority date||Oct 23, 2003|
|Also published as||US20050089031, WO2005043799A1|
|Publication number||10692585, 692585, US 7441179 B2, US 7441179B2, US-B2-7441179, US7441179 B2, US7441179B2|
|Original Assignee||Intel Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (24), Non-Patent Citations (2), Classifications (13), Legal Events (3)|
|External Links: USPTO, USPTO Assignment, Espacenet|
Networks enable computers and other devices to communicate. For example, networks can carry data representing video, audio, e-mail, and so forth. Typically, data sent across a network is divided into smaller messages known as packets. By analogy, a packet is much like an envelope you drop in a mailbox. A packet typically includes “payload” and a “header”. The packet's “payload” is analogous to the letter inside the envelope. The packet's “header” is much like the information written on the envelope itself. The header can include information to help network devices handle the packet appropriately. For example, the header can include an address that identifies the packet's destination. A given packet may “hop” across many different intermediate network devices (e.g., “routers”; “bridges” and “switches”) before reaching its destination.
A number of network protocols cooperate to handle the complexity of network communication. For example, a protocol known as Transmission Control Protocol (TCP) provides “connection” services that enable remote applications to communicate. That is, much like picking up a telephone and assuming the phone company will make everything in-between work, TCP provides applications on different computers with simple commands for establishing a connection (e.g., CONNECT and CLOSE) and transferring data (e.g., SEND and RECEIVE). Behind the scenes, TCP transparently handles a variety of communication issues such as data retransmission, adapting to network traffic congestion, and so forth.
To provide these services, TCP operates on packets known as segments. Generally, a TCP segment travels across a network within (“encapsulated” by) a larger packet such as an Internet Protocol (IP) datagram. The payload of a segment carries a portion of a stream of data sent across a network. A receiver can reassemble the original stream of data from the received segments.
Potentially, segments may not arrive at their destination in their proper order, if at all. For example, different segments may travel very different paths across a network. Thus, TCP assigns a sequence number to each data byte transmitted. This enables a receiver to reassemble the bytes in the correct order. Additionally, since every byte is sequenced, each byte can be acknowledged to confirm successful transmission.
Occasionally, data transmission errors may occur. For example, due to signal noise, a “1” bit within a segment may be accidentally changed to a “0” or vice-versa. To enable detection of errors, the TCP header includes a “checksum” field. The value of the checksum is computed by storing zeroes in the segment's checksum field and then summing each byte in the segment using an arithmetic operation known as “one's complement addition”.
Potentially, a segment may be modified multiple times.
A wide variety of similar approaches may be implemented. For example, instead of updating after each modification, an “adjustment value” may be accumulated based a series of packet modification and used to change the checksum only once.
Techniques described above may be used in a wide variety of implementations. For example,
In a thread-based implementation shown, the logic includes a packet receive thread 140 that performs initial operations on packets such as accumulating and storing the packets 140 in memory 152 as they arrive. A TCP thread 142 performs TCP operations on the segments such as maintaining a connection's TCP state, performing packet segmentation/reassembly, tracking sequence numbers sent/received/expected/acknowledged, and so forth (see Request for Comments (RFC) 793, 1122, and 1323).
The TCP thread 142 may notify an application thread 148 of a received segment. The application (e.g., an application operating at Layer 4 or greater with respect to the TCP/IP or Open Source Institute (OSI) protocol stack models) may perform a variety of operations on the segment payload including parsing and modifying data included in the packet payload. Examples of such applications include URL redirection, extensible Markup Language (XML) transaction monitoring, persistent HyperText Transfer Protocol (HTTP) cookie load balancing, and so forth.
As shown, the application 148 can invoke a variety of procedures 150 (e.g., instructions of methods, functions, macros, subroutines, etc.) that can automatically handle checksum update operations for the application 148. These operations include operations that track application reads and writes to the segment and incrementally update the checksum accordingly.
As shown in
As shown in
As shown in
As shown in
Eventually, as shown in
Again, the checksum techniques may be implemented in a variety of ways on a variety of platforms. For example,
The network processor 200 shown features a collection of packet processing engines 204 integrated on a single die. The engines 204 shown each offer multiple threads of execution to process packets. As shown, the processor 200 also includes a core processor 210 (e.g., a StrongARM® XScale®) that is often programmed to perform “control plane” tasks involved in network operations. The core processor 210, however, may also handle “data plane” tasks and may provide additional packet processing threads.
As shown, the network processor 200 includes interfaces 202 that can carry packets between the processor 200 and other network components. For example, the processor 200 can feature a switch fabric interface 202 (e.g., a Common Switch Exchange (CSIX) interface) that enables the processor 200 to transmit a packet to other processor(s) or circuitry connected to the fabric. The processor 200 can also include an interface 202 (e.g., a System Packet Interface (SPI) interface) that enables to the processor 200 to communicate with physical layer (PHY) and/or link layer devices. The processor 200 also includes an interface 208 (e.g., a Peripheral Component Interconnect (PCI) bus interface) to communicate, for example, with a host. As shown, the processor 200 also includes other components shared by the engines such as memory controllers 206, 212, a hash engine, and scratch pad memory.
The packet processing techniques described above may be implemented on a network processor, such as the network processor shown, in a wide variety of ways. For example, the threads described in
The incremental update operations provided can improve performance of a network processor 200. For example, the technique(s) can save engine computation cycles and reduce the memory bandwidth consumed in updating a checksum
As shown, the engine 204 includes a variety of local storage elements. For example, the engine 204 includes local memory 238, general purpose registers 236, and “next neighbor” registers 234 that enable the engine 204 to communicate directly with neighboring engines 204. The engine 204 also includes transfer registers 232 that buffer data sent to 232 a or received from 232 a other network processor 200 components such as the shared SRAM 212 or DRAM 206 controllers. The transfer registers 232 may be divided into two different sets of registers, e.g., one set for SRAM and one set for DRAM data.
The sample engine 204 shown provides multiple threads of execution. To support the multiple threads, the engine 204 includes program counters 222 for each thread. A thread arbiter 220 selects the program counter for a thread to execute. This program counter is fed to an instruction store 224 that outputs the instruction identified by the program counter to an instruction decode 226 unit. The instruction decode 226 unit may feed the instruction to an execution unit (e.g., an Arithmetic Logic Unit (ALU) and associated content addressable memory (CAM)) 230 for processing or may initiate a request to another network processor 200 component (e.g., a memory controller) via command queue 228.
Different implementations of checksum techniques described above may take advantage of the engine 204 architecture. For example, when a portion of segment data is retrieved from memory (e.g.,
In greater detail, the CAM entry 240 shown stores the base address 240 a of the packet 160 in memory (e.g., 152 in
The data 256 associated with a given segment can include the segment's current checksum value 242. The data 256 may also store data that maps a portion of the packet 160 to its cached location within the transfer registers 232 a (or other memory). For example, as shown, the data 256 may identify the starting 244 and ending 246 offset of a given portion relative to the start of a segment's payload. The data 256 may also include data to map the portion of the payload identified by the offsets 244, 246 to local storage. For instance, the data may identify the number 248, 252 of transfer registers storing the cached segment portion and the respective number of bytes 250, 254 within the registers used.
As an example, bytes 10 through 20 of a segment's payload may be read from memory and stored in 4-byte portions of two adjacent SRAM transfer registers followed by a 3-byte portion of a third transfer register. Thus, the starting offset 244 would have a value of 10 and the ending offset 246 would have a value of 20. The SRAM transfer registers used 248 would have a value of 3 and the number of SRAM transfer register bytes used 250 would have a value of 11. A write to byte-12 of the payload would fall within the starting 244 (10) and ending 246 (20) offsets. The transfer register data 248-250 can then be used to map the payload-relative byte number to a location within the transfer registers. That is, byte-12 of the payload would map to byte-3 in the first transfer register since byte-1 in the first transfer register is mapped to byte.10 of the payload. An incremental checksum update could be computed after the write.
Potentially, an incremental update of the checksum may not be possible in a given implementation. For example, an implementation may rely on an application to read payload data before writing to that piece of a segment. If this constraint is not honored by the application, the data being altered may not be in transfer registers 268. In such a case, the checksum may be invalidated 272 (e.g., by writing zero to the overall checksum value). Once invalidated, subsequent writes need not trigger 264 incremental checksum adjustment. Other implementations, however, may automatically read a given piece of the payload when a write “outside” the currently cached data occurs.
The technique(s) described above may be implemented in a variety of devices. For example, the checksum logic may be incorporated within a TCP Offload Engine (“TOE”) that at least partially alleviates the burden of TCP related operations on host processor(s).
The offload engine 306 may be implemented using a variety of components. For example, the engine 306 may include one or more network processors such as the IXP described above. Whether the offload engine uses the IXP, other network processor, or a design not featuring network processors (e.g., an Application Specific Integrated Circuit (ASIC) or other hardware, firmware, or software, implementing the incremental checksum update can potentially increase the overall throughput of the offload engine 306.
In addition to the TOE shown in
The term packet was sometimes used in the above description to refer to a TCP segment. However, the term packet also encompasses a frame, fragment, Asynchronous Transfer Mode (ATM) cell, and so forth, depending on the network technology being used.
The term circuitry as used herein includes hardwired circuitry, digital circuitry, analog circuitry, programmable circuitry (e.g., a processor or engine), and so forth. The programmable circuitry may operate on computer programs such as programs coded using a high level procedural or object oriented programming language. However, the program(s) can be implemented in assembly or machine language if desired. The language may be compiled or interpreted. Additionally, these techniques may be used in a wide variety of networking environments.
Other embodiments are within the scope of the following claims.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US5541920 *||Jun 15, 1995||Jul 30, 1996||Bay Networks, Inc.||Method and apparatus for a delayed replace mechanism for a streaming packet modification engine|
|US5935268 *||Jun 3, 1997||Aug 10, 1999||Bay Networks, Inc.||Method and apparatus for generating an error detection code for a modified data packet derived from an original data packet|
|US6269374 *||May 26, 1998||Jul 31, 2001||International Business Machines Corporation||Method and apparatus for updating checksums of data structures|
|US6557044 *||Jun 1, 1999||Apr 29, 2003||Nortel Networks Limited||Method and apparatus for exchange of routing database information|
|US6571291 *||May 1, 2000||May 27, 2003||Advanced Micro Devices, Inc.||Apparatus and method for validating and updating an IP checksum in a network switching system|
|US6601216||Mar 31, 2000||Jul 29, 2003||Microsoft Corporation||Differential cyclic redundancy check|
|US6629141 *||Jul 2, 2002||Sep 30, 2003||Intel Corporation||Storing a frame header|
|US6643821 *||Nov 30, 2000||Nov 4, 2003||Stmicroelectronics, Inc.||Method and device for computing incremental checksums|
|US6728930 *||Jul 13, 2001||Apr 27, 2004||Cirticom Corp.||Method for computing the internet checksum|
|US6802038 *||Dec 30, 2000||Oct 5, 2004||Arraycomm, Inc.||Cyclic redundancy check computation algorithm|
|US6886103 *||Oct 27, 2000||Apr 26, 2005||Lucent Technologies Inc.||Method and apparatus for extending network address translation for unsupported protocols|
|US6944168 *||May 4, 2001||Sep 13, 2005||Slt Logic Llc||System and method for providing transformation of multi-protocol packets in a data stream|
|US6957346 *||Jun 15, 1999||Oct 18, 2005||Ssh Communications Security Ltd.||Method and arrangement for providing security through network address translations using tunneling and compensations|
|US7079537 *||Apr 25, 2000||Jul 18, 2006||Advanced Micro Devices, Inc.||Layer 3 switching logic architecture in an integrated network switch|
|US7096399 *||Sep 11, 2003||Aug 22, 2006||Intel Corporation||Monitoring packet content|
|US7103821 *||Jul 3, 2002||Sep 5, 2006||Intel Corporation||Method and apparatus for improving network router line rate performance by an improved system for error checking|
|US7185153 *||Dec 18, 2003||Feb 27, 2007||Intel Corporation||Packet assembly|
|US7191433 *||Dec 29, 2003||Mar 13, 2007||Intel Corporation||Compiler for computer programming language including instruction statements for handling network packets|
|US7239635 *||Jun 27, 2002||Jul 3, 2007||International Business Machines Corporation||Method and apparatus for implementing alterations on multiple concurrent frames|
|US7260650 *||Nov 28, 2001||Aug 21, 2007||Cisco Technology, Inc.||Method and apparatus for tunneling information|
|US7266120 *||Nov 18, 2002||Sep 4, 2007||Fortinet, Inc.||System and method for hardware accelerated packet multicast in a virtual routing system|
|US20030076794||Apr 4, 2002||Apr 24, 2003||Takeshi Kawasaki||Checksum rewrite device|
|US20030169737 *||Mar 5, 2002||Sep 11, 2003||Lavigne Bruce E.||Method and apparatus for computing, storing, and multiplexing modified bytes in a packet router|
|EP0366589A2||Oct 10, 1989||May 2, 1990||International Business Machines Corporation||Method of maintaining integrity of data during message transmission in a data communication system|
|1||International Search Report, International App. No. PCT/US2004/034601, Applicant Ref. No. P17966PCT, Completion Date: Feb. 24, 2005, Date Mailed: Mar. 2, 2005, pp. 4.|
|2||PCT/US2004.034601 Int'l Preliminary Report on Patentability dated May 4, 2006.|
|International Classification||H03M13/09, H04L1/00|
|Cooperative Classification||H04L1/0045, H03M13/093, H04L1/0061, H04L1/0057, H04L1/0072|
|European Classification||H04L1/00B7B, H04L1/00B5, H04L1/00B7E, H04L1/00B8, H03M13/09D|
|Oct 23, 2003||AS||Assignment|
Owner name: INTEL CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:KRUEGER, JON;REEL/FRAME:014637/0619
Effective date: 20031021
|Apr 18, 2012||FPAY||Fee payment|
Year of fee payment: 4
|Apr 6, 2016||FPAY||Fee payment|
Year of fee payment: 8