Intel 82540EP/EM Network Card User Manual


 
Receive and Transmit Description
68 Software Developer’s Manual
3.5.9.3 TCP/IP/UDP Header for the Last Frame
The controller makes the following changes to the headers for the last frame of a TCP
segmentation context:
Note: Last frame payload bytes = PAYLEN – (N * MSS)
IPv4 Header
IP Total Length = (last frame payload bytes + HDRLEN) – IPCSS
IP Identification: incremented from last value (wrap around)
IP Checksum
IPv6 Header
Payload Length = MSS + HDRLEN - IPCSS
TCP Header
Sequence Number update: Add previous TCP payload size to the previous sequence
number value. This is equivalent to adding the MSS to the previous sequence number.
If FIN flag = 1b, set it in this last frame
If PSH flag =1b, set it in this last frame
TCP Checksum
UDP Header
UDP length: (last frame payload bytes + HDRLEN) - TUCSS
UDP Checksum
3.6 IP/TCP/UDP Transmit Checksum Offloading
The previous section on TCP Segmentation offload describes the IP/TCP/UDP checksum
offloading mechanism used in conjunction with TCP Segmentation. The same underlying
mechanism can also be applied as a standalone feature. The main difference in normal packet mode
(non-TCP Segmentation) is that only the checksum fields in the IP/TCP/UDP headers need to be
updated.
Before taking advantage of the Ethernet controller’s enhanced checksum offload capability, a
checksum context must be initialized. For the normal transmit checksum offload feature, this task
is performed by providing the Ethernet controller with a TCP/IP Context Descriptor with TSE = 0b
to denote a non-segmentation context. For additional details on contexts, refer to Section 3.3.5.
Enabling the checksum offloading capability without first initializing the appropriate checksum
context leads to unpredictable results. Once the checksum context has been set, that context, is used
for all normal packet transmissions until a new context is loaded. Also, since checksum insertion is
controlled on a per packet basis, there is no need to clear/reset the context.
The Ethernet controller is capable of performing two transmit checksum calculations. Typically,
these would be used for TCP/IP and UDP/IP packet types, however, the mechanism is general
enough to support other checksums as well. Each checksum operates independently and provides
identical functionality. Only the IP checksum case is discussed as follows.