TSO, GSO and GRO: Why Host Packet Counts Can Differ from the Wire

Follow the representation from host software to the link

Linux 6.18 describes sk_buff as its main packet-representation structure: the structure holds metadata, while associated buffers hold the data. Counting such objects answers a question about a particular point in the host stack. It does not automatically count external transmissions.

TCP segmentation offload, or TSO, lets supporting hardware divide a larger transmit object into smaller segments. The host supplies header locations and partial-checksum information for the remaining work. That prepared object is therefore distinct from the final transmitted representation. Generic segmentation offload, or GSO, supplies software segmentation when the relevant hardware offload cannot perform it.

Locate the observation relative to segmentation before interpreting a large host-side length. Seeing an object carrying several thousand data bytes does not establish that a same-sized Ethernet frame left the NIC, or that the path supports that frame size.

References: [K1][K2]

Follow 6,000 payload bytes through five segments

Consider a wholly fictional TCP transmission. Stipulate one host transmit object carrying 6,000 TCP payload bytes and a segmentation limit of 1,460 payload bytes per segment. Assume the segmentation fills each segment to that limit until the final remainder. These are teaching inputs, not specifications inferred for an actual NIC or path.

The payload lengths are 1,460 + 1,460 + 1,460 + 1,460 + 160 = 6,000 bytes. There are five data segments. A stipulated observation counting the object before segmentation records one; an observation counting the emitted segments records five. Assume each resulting IP packet occupies one Ethernet frame without further fragmentation.

Now stipulate exactly 40 bytes of combined IPv4 and TCP headers on every segment, with no options or tunnels. The first four IP packets each contain 1,500 bytes; the last contains 200 bytes. The counted IP total is 4 × 1,500 + 200 = 6,200 bytes, equivalently 6,000 + 5 × 40. This excludes every lower-layer byte and timing overhead, all return traffic and any additional transmissions.

The change from one object to five segments has preserved the 6,000 payload bytes and added per-segment headers to the transmitted representation. It has not created five times the payload or four missing packets. The 1,460-byte limit was stipulated; deriving an actual segment limit from MTU, headers and path constraints is a separate sizing question.

Receive aggregation changes the count in the other direction

Linux 6.18 describes Generic Receive Offload, or GRO, as the complement to GSO: receive traffic can be assembled into larger host representations.

Extend the fictional case by stipulating that all five data frames arrive at a receiving NIC, and that a later aggregation step represents their payload in one software object. The arrival observation counts five frames; the later observation counts one object. The arithmetic supplies no missing-frame event. Real aggregation eligibility and grouping depend on the implementation and traffic; this illustrative five-to-one grouping is not a universal rule.

The later object also says nothing by itself about how many reads the application performs or which application operation completes. RFC 9293, section 3.7, explains that TCP segment boundaries do not generally correspond to application read or write boundaries. Five TCP data segments consequently do not establish five independent application requests.

References: [K1][R1]

A counter named packets still needs its definition

Linux 6.18's mlx5 Ethernet counter documentation supplies a concrete example. For hardware-accelerated GRO, rx[i]_gro_packets counts the qualifying received packets, while rx[i]_gro_skbs counts the constructed software objects. Both definitions restrict their population to aggregation with a GRO count greater than one. They describe related activity using different objects.

The same document places physical-port counters at the external port connecting the adapter to the network. Those observations occupy a different boundary from host software processing. These are definitions for the cited mlx5 documentation, not a universal naming scheme for NICs.

Do not assign the fictional one-to-five conversion to an arbitrary dashboard field. Its definition must establish whether it counts software objects, represented segments, external frames or another event. A host-reported field can use accounting rules beyond a simple count of objects. The word packets alone cannot supply the conversion.

References: [K3]

Compare NIC evidence using the same counted population

Suppose one supplier reports host processing in objects per second and another reports external transmission in frames per second. A larger numerical result cannot rank the NICs until the buyer knows what each unit represents. Even an identical observation duration leaves different object definitions unresolved.

Have each report retain its observation location, exact field definition, transmit or receive direction and interval. Establish whether it covers the same traffic population and whether its numerator is an interval count or an accumulated total. Keep the offered NIC, driver and operating-system context with the report, including the segmentation or aggregation behavior relevant to that observation.

Use byte quantities with equal care. The fictional case contains 6,000 TCP payload bytes and 6,200 transmitted IP bytes. Comparing those values as though both measured application content would invent 200 bytes of additional useful work. Retransmissions, other traffic or different header accounting would require their own explanation before applying any conversion to a real report.

A loss claim needs evidence tracking comparable traffic across the relevant boundaries; subtracting unlike object counts does not supply it. A delivery claim needs evidence at the receiving application boundary. Neither the sender's prepared object nor a NIC's transmission count demonstrates that the intended application consumed the data. If the purchase depends on completed application work, request a result defined at that boundary alongside the NIC evidence.

Keep packet representation separate from resource and congestion claims

The linked RSS article explains distribution of receive-processing work among queues. The SR-IOV article explains device-function allocations and their physical-port relationships. Neither queue distribution nor function allocation is a conversion between a large transmit object and its emitted segments.

The TAP-versus-SPAN article addresses which traffic an acquisition path can represent. That coverage question remains separate from the host's later representation of traffic. The RoCE article distinguishes priority pauses, congestion markings and receiver notifications; those signals are not segmentation or receive aggregation.

TSO, GSO and GRO add no physical lanes or external ports. They also create no application transactions merely by changing the number of packet representations. Use the linked owners for those adjacent decisions, then return to the actual boundary of the packet-rate claim.

Use the selected physical ports to scope cabling

If the equipment decision also requires physical cabling, carry the approved port and endpoint schedule into that inquiry. The number of host packet objects or emitted segments supplies no cable quantity.

Leviathan's Structured Cabling & Fiber Installation service can discuss agreed installation, routing, dressing, labeling, physical checks and connection records using customer-furnished or separately sourced compatible materials. Use the service and project-inquiry links below to share the approved connections, routes, appointed materials supplier, site constraints and required records.

NIC configuration, packet-analysis interpretation and application verification remain with the appointed network and platform owners. This educational comparison supplies no field procedure or approval to alter an operating connection.

References: [L1]