SKB CHECKSUMS(9)

📦 version 7.3.1, in nixpkgs unstable

💅 skb checksums 💅

okay so bestie, this is the skb checksums(9) page from the Kernel API Manual — part 1 of 2, and we are doing a full vibe check on every flag, value, and caveat. No skipping, no cap. The whole interface for checksum offload between the stack and networking drivers is as follows...

Drivers advertise checksum offload capabilities in the features of a device. From the stack's point of view these are capabilities offered by the driver. A driver typically only advertises features that it is capable of offloading to its device.

the feature table is named Checksum related device features and has :widths: 1 10, so here are the rows:

  • NETIF_F_HW_CSUM — The driver (or its device) is able to compute one IP (one's complement) checksum for any combination of protocols or protocol layering. The checksum is computed and set in a packet per the CHECKSUM_PARTIAL interface (see below). main character energy, honestly.
  • NETIF_F_IP_CSUM — Driver (device) is only able to checksum plain TCP or UDP packets over IPv4. These are specifically unencapsulated packets of the form IPv4|TCP or IPv4|UDP where the Protocol field in the IPv4 header is TCP or UDP. The IPv4 header may contain IP options. This feature cannot be set in features for a device with NETIF_F_HW_CSUM also set. This feature is being DEPRECATED (see below). lowkey old school.
  • NETIF_F_IPV6_CSUM — Driver (device) is only able to checksum plain TCP or UDP packets over IPv6. These are specifically unencapsulated packets of the form IPv6|TCP or IPv6|UDP where the Next Header field in the IPv6 header is either TCP or UDP. IPv6 extension headers are not supported with this feature. This feature cannot be set in features for a device with NETIF_F_HW_CSUM also set. This feature is being DEPRECATED (see below). also lowkey old school.
  • NETIF_F_RXCSUM — Driver (device) performs receive checksum offload. This flag is only used to disable the RX checksum feature for a device. The stack will accept receive checksum indication in packets received on a device regardless of whether NETIF_F_RXCSUM is set. not me thinking it's a full on/off switch — it's specifically the disable knob, bestie.

🫶 Checksumming of received packets by device 🫶

Indication of checksum verification is set in sk_buff.ip_summed. Possible values are:

  • CHECKSUM_NONE — Device did not checksum this packet e.g. due to lack of capabilities. The packet contains full (though not verified) checksum in packet but not in skb->csum. Thus, skb->csum is undefined in this case. so do not trust that field, fr fr.
  • CHECKSUM_UNNECESSARY — The hardware you're dealing with doesn't calculate the full checksum (as in CHECKSUM_COMPLETE), but it does parse headers and verify checksums for specific protocols. For such packets it will set CHECKSUM_UNNECESSARY if their checksums are okay. sk_buff.csum is still undefined in this case though. A driver or device must never modify the checksum field in the packet even if checksum is verified. iconic boundary, honestly.
    • TCP: IPv6 and IPv4.
    • UDP: IPv4 and IPv6. A device may apply CHECKSUM_UNNECESSARY to a zero UDP checksum for either IPv4 or IPv6, the networking stack may perform further validation in this case.
    • GRE: only if the checksum is present in the header.
    • SCTP: indicates the CRC in SCTP header has been validated.
    • FCOE: indicates the CRC in FC frame has been validated.

sk_buff.csum_level indicates the number of consecutive checksums found in the packet minus one that have been verified as CHECKSUM_UNNECESSARY. For instance if a device receives an IPv6->UDP->GRE->IPv4->TCP packet and a device is able to verify the checksums for UDP (possibly zero), GRE (checksum flag is set) and TCP, sk_buff.csum_level would be set to two. If the device were only able to verify the UDP checksum and not GRE, either because it doesn't support GRE checksum or because GRE checksum is bad, skb->csum_level would be set to zero (TCP checksum is not considered in this case). the way that math works is so specific and I respect it.

  • CHECKSUM_COMPLETE — This is the most generic way. The device supplied checksum of the _whole_ packet as seen by netif_rx and fills in sk_buff.csum. This means the hardware doesn't need to parse L3/L4 headers to implement this. Notes:
    • Even if device supports only some protocols, but is able to produce skb->csum, it MUST use CHECKSUM_COMPLETE, not CHECKSUM_UNNECESSARY.
    • CHECKSUM_COMPLETE is not applicable to SCTP and FCoE protocols.
  • CHECKSUM_PARTIAL — A checksum is set up to be offloaded to a device as described in the output description for CHECKSUM_PARTIAL. This may occur on a packet received directly from another Linux OS, e.g., a virtualized Linux kernel on the same host, or it may be set in the input path in GRO or remote checksum offload. For the purposes of checksum verification, the checksum referred to by skb->csum_start + skb->csum_offset and any preceding checksums in the packet are considered verified. Any checksums in the packet that are after the checksum being offloaded are not considered to be verified. so if it's after, do not count it verified — periodt.

💅 Checksumming on transmit for non-GSO 💅

The stack requests checksum offload in the sk_buff.ip_summed for a packet. Values are:

  • CHECKSUM_PARTIAL — The driver is required to checksum the packet as seen by hard_start_xmit from sk_buff.csum_start up to the end, and to record/write the checksum at offset sk_buff.csum_start + sk_buff.csum_offset. A driver may verify that the csum_start and csum_offset values are valid values given the length and offset of the packet, but it should not attempt to validate that the checksum refers to a legitimate transport layer checksum -- it is the purview of the stack to validate that csum_start and csum_offset are set correctly.

When the stack requests checksum offload for a packet, the driver MUST ensure that the checksum is set correctly. A driver can either offload the checksum calculation to the device, or call skb_checksum_help (in the case that the device does not support offload for a particular checksum).

NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM are being deprecated in favor of NETIF_F_HW_CSUM. New devices should use NETIF_F_HW_CSUM to indicate checksum offload capability. skb_csum_hwoffload_help can be called to resolve CHECKSUM_PARTIAL based on network device checksumming capabilities: if a packet does not match them, skb_checksum_help or skb_crc32c_help (depending on the value of sk_buff.csum_not_inet, see the crc reference) is called to resolve the checksum.

the driver MUST ensure the checksum is set correctly. not "should", not "maybe", MUST. fr fr. 👑
  • CHECKSUM_NONE — The skb was already checksummed by the protocol, or a checksum is not required. chill.
  • CHECKSUM_UNNECESSARY — This has the same meaning as CHECKSUM_NONE for checksum offload on output. same vibe, different name.
  • CHECKSUM_COMPLETE — Not used in checksum output. If a driver observes a packet with this value set in skbuff, it should treat the packet as if CHECKSUM_NONE were set. do not invent new behavior, bestie.
tiny anchor checkpoint: .. _crc: goes right here in the original, so the crc reference above has somewhere to land. iykyk.

🧚 Non-IP checksum (CRC) offloads 🧚

the original has a FLAT-TABLE: with :widths: 1 10, and the rows are:

  • NETIF_F_SCTP_CRC — This feature indicates that a device is capable of offloading the SCTP CRC in a packet. To perform this offload the stack will set csum_start and csum_offset accordingly, set ip_summed to CHECKSUM_PARTIAL and set csum_not_inet to 1, to provide an indication in the skbuff that the CHECKSUM_PARTIAL refers to CRC32c. A driver that supports both IP checksum offload and SCTP CRC32c offload must verify which offload is configured for a packet by testing the value of sk_buff.csum_not_inet; skb_crc32c_csum_help is provided to resolve CHECKSUM_PARTIAL on skbs where csum_not_inet is set to 1. ate.
  • NETIF_F_FCOE_CRC — This feature indicates that a device is capable of offloading the FCOE CRC in a packet. To perform this offload the stack will set ip_summed to CHECKSUM_PARTIAL and set csum_start and csum_offset accordingly. Note that there is no indication in the skbuff that the CHECKSUM_PARTIAL refers to an FCOE checksum, so a driver that supports both IP checksum offload and FCOE CRC offload must verify which offload is configured for a packet, presumably by inspecting packet headers. so you gotta look at headers — slay.

🌈 Checksumming on output with GSO 🌈

In the case of a GSO packet (skb_is_gso is true), checksum offload is implied by the SKB_GSO_* flags in gso_type. Most obviously, if the gso_type is SKB_GSO_TCPV4 or SKB_GSO_TCPV6, TCP checksum offload as part of the GSO operation is implied. If a checksum is being offloaded with GSO then ip_summed is CHECKSUM_PARTIAL, and both csum_start and csum_offset are set to refer to the outermost checksum being offloaded (two offloaded checksums are possible with UDP encapsulation). iconic, honestly.

and that's where part 1 stops, bestie — part 2 is next and there's more page to go 💅

💅 the deep-lore reading list, aka the SEE ALSO section

okay bestie, you made it to the end and now you get the bonus round ✨ — every single cross-reference on this page, in order, no skipping, because some of these are lowkey the whole personality of the skb code. Go click around, iykyk 🫶

First up, the mothership itself — Kernel file ./include/linux/skbuff.h — and then the frag girlies, who handle all the fragment size math:

Then the ✨concept✨ pages — timestamp structs, datarefs, geometry, and the main character herself, struct sk_buff:

  • struct skb_shared_hwtstamps(9)
  • dataref and headerless skbs(9)
  • Basic sk_buff geometry(9)
  • struct sk_buff(9)

🎀 dst land + napi + the refcount/free squad:

Allocation, padding, queue vibes, and the clone/share/unshare trio (they're a package deal, fr fr):

🌷 peek at the queue, check the length, splice it, init it, dequeue it — the whole queue choreography:

Filling page descs, headroom/tailroom math, and the carefully-named header setters (yes they're careful, that's the whole point 😭):

🦋 the alloc family expands — frags, skbs, and dev pages:

Frag offsets, net iovs, pages, netmems, addresses, phys, copies and the DMA map — the frag extended universe 💫:

Copy-on-write era 👑 — clone_writable, cow, cow_head, the padto trio, and the linearize squad:

rcsum fixups, the linearize check, and every timestamp/data-move entry you could ever want ⏰:

and the final four, saving the checksum completion for last because of course 💖:

and that's the whole page, bestie — you're officially an skb checksum girlie now 🎓💅 This one comes to you from the kernel source at ./include/linux, dated October 2026, and it's the skb checksums(9) page — go forth and checksum responsibly ✨🫶💜

📦 where this page comes from