A small TCP write does not always trigger an immediate packet transmission on Linux. With TCP autocorking enabled, the stack can defer a new small send when an earlier packet from the same flow is still waiting in a qdisc or device transmit queue, giving a following write a chance to join the pending data.
The mechanism targets packet count rather than application-visible buffering semantics. A successful write() or sendmsg() still reports bytes accepted by the socket; autocorking influences when queued bytes advance into transmission.
Queue state gates automatic corking
The net.ipv4.tcp_autocorking sysctl controls the behavior and is enabled by default. The kernel documentation places a specific boundary on the optimization: coalescing applies when at least one prior packet for the flow remains queued in the qdisc or device transmit path.
That condition makes autocorking different from a fixed delay applied to every short write. A flow with no earlier packet waiting downstream does not gain the same automatic hold solely because the current write is small. The optimization reacts to existing transmit backlog.
This coupling also means identical application write patterns can produce different packetization depending on queue timing. Device speed, qdisc behavior, pacing, CPU scheduling, and traffic load can alter whether the prior packet is still present when the next send reaches the TCP stack.
Consecutive writes can share packetization
Applications often construct a logical record through several adjacent writes: a header followed by metadata and a payload, for example. Without coalescing, short boundaries at the socket API can contribute to additional packets or smaller segments.
Autocorking can keep pending bytes in the TCP write queue long enough for a nearby send to extend the data already awaiting transmission. The resulting packet layout is still constrained by TCP state, congestion control, the advertised receive window, MSS, segmentation offload, and other transmit rules. Autocorking is one input to packet formation, not a guarantee that a set of writes becomes one wire packet.
The distinction matters on systems using TSO or GSO. Kernel packet buffers and packets observed on a physical link do not necessarily have a one-to-one relationship. Coalescing application writes can reduce work before segmentation while later offload stages can split a larger unit for transmission.
Autocorking is separate from TCP_CORK
TCP_CORK gives an application explicit control over withholding partial frames until the application clears the option or other stack conditions force progress. Autocorking is an internal heuristic and does not require socket-option changes.
The kernel documentation explicitly retains TCP_CORK as the stronger choice for applications that possess precise record-boundary information. The application can signal a deliberate batching interval instead of relying on whether a previous packet happens to remain in a downstream queue.
MSG_MORE provides another application-level signal for a send operation whose data is followed by more data. These interfaces encode intent at the call site. Autocorking instead infers a batching opportunity from write size and transmit state.
Latency and packet count pull in opposite directions
Holding a short write can reduce packet count and per-packet processing, but any hold also creates a latency boundary. The autocorking condition limits that tradeoff by tying the decision to a packet already waiting for transmission rather than introducing a general-purpose timer for all small sends.
For bulk or bursty traffic, the extra coalescing opportunity can reduce protocol and device work. For latency-sensitive traffic, explicit application behavior and observed packet timing remain more informative than assuming each successful send maps immediately to a transmitted segment.
Disabling net.ipv4.tcp_autocorking removes this particular automatic heuristic, but it does not disable Nagle behavior, qdisc scheduling, pacing, congestion-window limits, segmentation offload, or application-directed corking. Packet timing can therefore remain delayed or aggregated for independent reasons.
Packet traces expose the combined transmit path
A trace showing fewer packets than application send calls is consistent with autocorking, but it is not sufficient evidence by itself. TCP can combine data through several mechanisms, and capture location can expose traffic before or after software and hardware segmentation.
Useful attribution separates application call boundaries, socket configuration, the autocorking sysctl, qdisc state, and the capture point. The key observable boundary is not simply small versus large writes. It is whether a later small send arrives while earlier data for that flow is still queued deeply enough for the TCP autocorking condition to apply.