USPatent applicationPatented

Method and apparatus for offloading checksum

Granted 4 Mar 2003 · 1 office action

Assignee: Intel Corporation

Law firm: Law firm · Log in to unlock

Attorney: Attorney · Log in to unlock

Inventors: Timothy E. W. Labatte · Examiner: Stephen M. Baker · AU 2133 · TC 2100

Application· this page
9471986
filed 23 Dec 1999
Publication
Not published
not published
Patent
US 6,530,061
granted 4 Mar 2003

Life of the application

7 dated events
⤢ drag to zoom20002002200420062008201020122014201620182020ProsecutionOwnershipTerm & fees
ProsecutionOwnershipTerm & feeshover for detail · click to open

Abstract

A media access controller for a network interface card accommodates protocol checksum offloads by calculating a hardware assisted checksum for an indiscriminate region of a packet including all or part of the layer 2 header, all of the layer 3 header, all of the layer 4 header, and all data payload areas of the packet. The hardware assisted checksum is then adjusted by software which subtracts non-relevant fields within the packet from the hardware assisted checksum and then verifies the checksum.

Description

5 parts
›BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to Network Interface Cards, and more particularly, to a method and apparatus for off-loading a checksum calculation to a Network Interface Card.

2. Description of the Related Art

A Network Interface Card (NIC) is a hardware device that allows a computer to communicate over a network. A NIC is installed on the computer and controlled by software known as a NIC driver which is loaded into memory by the computer's operating system. A NIC driver is typically supplied by either the manufacturer of the NIC or by a third party, and is written to comply with the requirements of the operating system of the computer on which it will be used.

A NIC driver performs low level networking tasks specific to the NIC hardware in support of other software drivers known as protocols (also referred to as protocol drivers or transport drivers) which perform higher level networking functions. Some examples of commonly used protocols are Transmission Control Protocol/Internet Protocol (TCP/IP), NetBIOS Extended User Interface (NetBEUI, where NetBIOS refers to Network Basic Input/Output Specification), and Internet Packet Exchange/Sequenced Packet Exchange (IPX/SPX).

The Microsoft Windows NT 4.0 operating system includes a driver interface known as Network Driver Interface Specification version 4.0 (NDIS 4.0) through which NIC drivers communicate with protocols, the operating system, and one or more NICs. NDIS forms what is known as a “wrapper” around NIC drivers to abstract the NIC driver from hardware and protocols. This improves the portability of the driver code. NDIS also provides a library of routines which NIC drivers can use to perform many standardized networking tasks, thereby making it easier to create NIC drivers.

In NDIS 4.0, protocol drivers such as TCP/IP drivers must perform layer 4 (TCP) and layer 3 (IP) checksum validation. A newer version of NDIS (sometimes referred to as NDIS 5.0) is included in the Microsoft Windows 2000 operating system. NDIS in Windows 2000 retains the basic requirements, services and architecture of earlier versions, but also provides procedures for off-loading certain tasks to a NIC. One such off-loadable task is the validation of layer 3 and 4 (e.g., TCP/IP) checksums.

›SUMMARY OF THE INVENTION

In accordance with the present invention, a hardware assisted checksum is calculated for an indiscriminate region of a packet.

›BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an embodiment of a system in accordance with the present invention.

FIG. 2 illustrates the regions of a packet for which an embodiment of the present invention generates a hardware assisted checksum.

FIG. 3 is a flow diagram illustrating the operation of an embodiment of a NIC driver in accordance with the present invention.

FIG. 4 illustrates the regions of a packet for which another embodiment of the present invention generates a hardware assisted checksum.

›DETAILED DESCRIPTION · 1 of 2

An exemplary embodiment of the present invention will first be described briefly, followed by a more detailed description.

Referring to FIG. 1, an embodiment of a system in accordance with the present invention is shown generally at 10 . The system includes a host computer 12 having a network interface card (NIC) 14 which is interfaced to the host computer through a bus 26 such as an Industry Standard Architecture (ISA) bus, an Extended Industry Standard Architecture (EISA) bus, or directly through a PCI bus.

The NIC includes a media access controller (MAC) 16 which is preferably an integrated circuit chip and is connected to the network media (i.e., network hardware) 18 . The NIC also includes a processor 20 which interfaces the NIC, including the MAC, to the host computer. The processor 20 is preferably a microprocessor integrated circuit chip controlled by memory 22 which can be external to the processor or integrated into the chip.

In operation, the MAC calculates a hardware assisted checksum for an indiscriminate region of a packet including all or part of the layer 2 header, all of the layer 3 header, all of the layer 4 header, and all data payload areas of the packet. This region is shown as a portion of the packet of FIG. 2 . “Indiscriminate” means that the hardware begins calculating the checksum starting at a given location in the packet without regard to whether it is including the layer 2 header, layer 3 header, etc. in the checksum.

After the MAC generates the hardware assisted checksum, the processor 20 passes the hardware assisted checksum to a NIC driver on the host computer which verifies the layer 4 checksum by subtracting non-relevant fields within the packet from the hardware assisted checksum and then comparing the result to the checksum value supplied with the layer 4 header. The non-relevant fields include any portions of the layer 2 header that were included in the hardware assisted checksum, and all layer 3 header fields that are not part of the layer 4 pseudo header. The NIC driver then indicates the success or failure of the checksum verification to the host computer.

The exemplary embodiment of the present invention shown in FIG. 1 will now be described in more detail.

The network media 18 and MAC 16 comply with Ethernet, which is a popular Local Area Network (LAN) specification that is based on American National Standards Institute/The Institute of Electrical and Electronics Engineers, Inc. Standard 802.3 (also referred to as ANSI/IEEE 802.3, or simply “802.3”).

The MAC calculates a hardware assisted checksum on the entire packet excluding the first fourteen bytes (bytes 0-13) and the layer 2 cyclical redundancy check (CRC). In a preferred embodiment, the MAC uses microcode to calculate the hardware assisted checksum. When the MAC receives a packet through the network media, it passes the packet and hardware assisted checksum to the processor which then relays this information to the NIC driver on the host computer.

Byte 14 was chosen as the starting point for the hardware assisted checksum. Other starting points could be utilized. However, byte 14 is a convenient starting point because the MAC header (layer 2 header) for standard IEEE 802.3 frames is 14 bytes long. Therefore, if standard frames are used, the hardware assisted checksum does not need to be adjusted for the layer 2 header.

If this embodiment is used with extended (“snap”) type frames, which add an additional 5 bytes to the MAC header, a portion of the layer 2 header after byte 14 is included in the hardware assisted checksum, and therefore, will need to be subtracted out of the hardware assisted checksum when it is adjusted.

The processor 20 is preferably an Intel 960 microprocessor. The processor performs the communication tasks associated with interfacing the MAC to the host computer. The NIC communicates with the NIC driver the through transmit and receive buffers. When the processor on the NIC receives a packet and hardware assisted checksum from the MAC, it passes them to the NIC driver by posting the packet to the receive buffer with the hardware assisted checksum appended at the end of the packet. The NIC can be configured to post the layer 2 CRC to the receive buffer, in which case the hardware assisted checksum follows the CRC.

Referring again to FIG. 1, the host computer 12 has NDIS 5.0 installed thereon. As mentioned above, NDIS 5.0 is included in the Microsoft Windows 2000 operating system.

Complete documentation on Windows 2000 is provided in the Driver Developer's Kit (DDK) for Windows 2000 which is published by Microsoft Corporation and is accessible through the internet at the following Universal Resource Locator (URL):

www.microsoft.com./ddk/.

NDIS for Windows 2000 provides procedures for a protocol to query, enable, and utilize the task off-load capabilities of a network interface card (NIC). A NIC is typically supported by a NIC driver known as an NDIS miniport driver (also referred to as a “miniport”) which passes packets of data back and forth to the NIC through send and receive buffers.

When a protocol queries a miniport for its NIC's off-load capabilities, the miniport responds by indicating the checksum capabilities of its NIC through the structure NDIS_TASK_TCP_IP_CHECKSUM which is defined in NDIS and passed through an information buffer. This structure allows a miniport to report whether its NIC can validate checksums for TCP, IP, and UDP in either IPv4 and IPv6.

Once a miniport reports the checksum capabilities of its NIC to a protocol, the protocol enables the checksum capabilities by passing a special header through the information buffer. The protocol and miniport then communicate information about task off-load operations using various structures and pointers to access per-packet information as out-of-band data as specified in the DDK for Windows 2000. Although NDIS allows a miniport to report that its NIC can validate checksums for TCP, IP, and UDP in both IPv4 and IPv6, the initial release of Windows 2000, NDIS supports neither UDP, nor IPv6. Therefore, the exemplary embodiment is described in the context of TCP/IP and IPv4. However, the invention is not so limited, and in a preferred embodiment, the miniport performs the requisite steps to determine which protocol queried its checksum capabilities and then responds accordingly.

›DETAILED DESCRIPTION · 2 of 2

In the system of FIG. 1, the NIC driver is a miniport written to support the NIC's checksum offload capabilities. Therefore, it reports its task off-load capabilities as discussed above. When the miniport receives a packet and hardware assisted checksum from the NIC, and the NIC's checksum off-load capabilities are enabled, the miniport adjusts the hardware assisted checksum to verify the layer 4 checksum using the process shown in FIG. 3 .

Beginning at 100 , the miniport obtains the packet and hardware assisted checksum for the packet from the NIC. At 102 , the miniport subtracts any of the layer 2 header that was included in the hardware assisted checksum. As discussed above, none of the layer 2 header would be included in the hardware assisted checksum if standard Ethernet frames are used. At 104 , the miniport determines if the layer 4 checksum includes a layer 3 pseudo header. If it does, the miniport subtracts non-relevant layer 3 header fields leaving only the relevant pseudo header fields at 106 . Otherwise, at 108 , the miniport subtracts the entire layer 3 header.

At 110 , the miniport adds back any borrows that were needed during the previous subtraction operations, thereby generating an adjusted hardware assisted checksum. At 112 , the adjusted hardware assisted checksum is evaluated to determine if the layer 4 checksum verification is successful. Because the layer 4 checksum, which is located in the layer 4 header, is included in the hardware assisted checksum, the adjusted hardware assisted checksum will equal zero if the checksum verification is successful. The miniport indicates layer 4 checksum success or failure at 114 or 116 in accordance with the results. The miniport then indicates layer 4 checksum success/failure to NDIS using the appropriate NDIS structure.

Although the MAC shown in FIG. 1 does not include the layer 2 CRC in the hardware assisted checksum as shown in FIG. 2, it can alternatively be adapted to do so, in which case, the miniport must subtract the layer 2 CRC back out during the checksum verification process.

In the embodiment described above, the hardware assisted checksum is adjusted by the miniport. However, the processor 20 and the NIC can also be adapted to perform the adjustment shown in FIG. 3 under the instruction of program code stored in memory 22 . In this case, rather than passing the hardware assisted checksum to the miniport, the processor on the NIC would simply indicate success/failure of the layer 4 checksum to the miniport, which would then indicate the checksum success/failure to NDIS.

The MAC of FIG. 1 is shown as part of the NIC. However, a MAC which generates a hardware assisted checksum for an indiscriminate region of a packet as described above can also be utilized in other ways. For example, it can be incorporated directly into the motherboard of the host computer, in which case the hardware assisted checksum can be adjusted by any hardware or software that is capable of determining the non-relevant regions of the packet and subtracting them from the hardware assisted checksum. It should also be noted that the hardware assisted checksum could also be generated by the processor on the NIC and then passed to the miniport in the receive buffer in the same manner as described above.

Having described and illustrated the principles of the invention in a preferred embodiment thereof, it should be apparent that the invention can be modified in arrangement and detail without departing from such principles. I claim all modifications and variations coming within the spirit and scope of the following claims.

Claims as granted

28 claims

Log in to read the claims of this application.

Log in to unlock

Classifications

2 codes
IPC · International Patent Classification
Section H — Electricity
  • H03M13/09
USPC · US Patent Classification
714/807

Claim changes

Soon
Coming soonHow the claims changed between publication and grant

See which claims were amended, added or cancelled during examination, with every added and removed word marked.

AmendedAddedCancelledUnchanged

The published claims of this application are not paired with the granted ones in what we hold.

File wrapper

⤢ drag to zoomJan 2000Jul 2000Jan 2001Jul 2001Jan 2002Jul 2002Jan 2003USPTOApplicantNon-final rejectionResponse after non-final
USPTOApplicanthover for detail · click to open
Pendency
3.2 y
1,167 days filing → grant
Office actions
1
non-final + final
Responses
1
no RCE
Examiner
Stephen M. Baker
art unit 2133 · TC 2100
Citations: 12 back · 39 forward

See the full prosecution history — every USPTO and applicant action on this file, in order.

Log in to unlock

Documents

Log in to open the documents of this file: the application as filed, every office action and response, the notice of allowance.

Log in to unlock

Chain of title

⤢ drag to zoom20002002200420062008201020122014201620182020Owner 1
Titlehover for detail · click to open

See the full assignment history — every owner this patent has passed through, with recordation dates and reel/frame numbers.

Log in to unlock