🧩 Selective offload — not a TOE
Accelerate the common path near the NIC while keeping correctness-heavy transport state in host software.
6.1 Splitting TCP host/device
The question selective offload answers. TCP is cheap in the steady state and expensive in the corners. The steady state is arithmetic and bookkeeping you would happily hand to hardware: bump a sequence number, fold a checksum, recognise an in-order segment, emit an ACK, transmit the next allowed byte. The corners are where correctness lives: a segment arrives out of order and must be held and reassembled, a timer fires and a buffered range must be retransmitted, the congestion window must shrink, the receive window must be honoured so you never overrun the peer. A full TCP-offload engine (TOE) moves both halves into silicon and ends up freezing a subtle, evolving state machine into opaque hardware. The Solarflare lineage refuses that bargain. It splits the connection so the cheap, repetitive half runs near the NIC and the correctness-heavy half stays in host software.
`US9674318B2` — TCP processing for devices. This is the cleanest statement of the split. The host transport engine establishes and maintains the full transport state for a connection — it does the handshake, owns the windows, knows the whole picture. Then, for selected streams, it hands enough of that state to a device transport engine so the device can do fast-path work on behalf of a device-side application: process received data, transmit data, manage sequence numbers, compute and check checksums, handle ACKs, and transmit up to a bounded permission the host grants. Crucially, the responsibilities that need memory and judgement do not go to the device. Out-of-sequence receive data, retransmit buffering, and ACK/retransmission authority can stay with the host. The device is given a fast lane for the common case and a hard ceiling on what it may do; anything outside that lane falls back to the host that still owns the connection.
`US10873613B2` — the same split, made explicit as a protocol. The related patent continues the host/device division and sharpens the control relationship. The device transport engine monitors stream state and performs transport processing only when authorized by host-side software — it does not independently own the connection. The emphasis is on giving the device just enough state to accelerate one selected stream while the host retains control. That word authorized is the whole design: there is an explicit handoff and an explicit leash, because stale or excessive device-side authority over sequence numbers, windows, or retransmission would silently break TCP.
Why this is reliability near the NIC, not inside it. The tradeoff is deliberate. A TOE promises to take TCP off the host entirely, but it pays for it: the hardware now has to implement reorder queues, retransmit buffers, congestion control, and every RFC corner — and when the stack needs to evolve (new congestion algorithms, new options, a bug fix), you are stuck with what shipped in the ASIC. Opaque hardware TCP is also hard to debug, hard to make multi-tenant-safe, and tends to diverge from the host's own stack. The host/device split keeps the expensive, slow-changing, correctness-defining state in software that can be inspected, patched, and trusted, while letting hardware do the fast-path arithmetic for the streams that actually need ultra-low latency. The device accelerates; the host remains the authority.
Why it matters for the datapath. For an FPGA or device-side application that needs TCP payloads now, this gets the latency win without a full stack in silicon. The price is an explicit control protocol between host and device — state handoff, bounded permissions, revocation, fallback when a segment arrives out of order. That boundary is exactly what an interviewer will probe: what is the minimum state a device needs to safely process a stream, what must it never be allowed to decide, and how does the host claw authority back when the fast path hits a case it was never given permission to handle.
Sources
6.2 Near-NIC messages & segmentation
The theme. Once you accept that full TCP should not live in silicon, a different opportunity opens up: there is a lot of repetitive, latency-sensitive work around TCP — shaping segments, building headers, parsing upper-layer messages — that you can push toward the device without owning the transport state machine. The patents in this group all do that. They speculate, shape, and parse near the NIC, and they keep the host as the correctness authority that can validate or roll back.
`US9003053B2` — message acceleration (speculate, then let the host invalidate). A NIC-side or peripheral message engine processes upper-layer messages carried over TCP before full host TCP processing has completed. The target is low-latency message protocols such as FIX, where many useful messages conveniently align with TCP segment boundaries — so the engine can lift out and act on a complete message from a single segment without waiting for the host stack to finish. The host still receives enough packet and header information to validate the work. If packets turn out to be out of sequence, incomplete, corrupted, or otherwise unsafe, the host discards the accelerated result and redoes the processing in software. This is speculative execution near the NIC with explicit rollback: do the useful work early, get the latency, but make the undo path a first-class part of the design and keep ordering and transport semantics anchored in the host.
`US9077751B2` — driver-level segmentation. Repetitive transmit shaping moves down to the driver rather than into NIC silicon. The driver advertises a segmentation capability to the OS, then accepts one large “superpacket” and forms the per-segment headers, computes offsets and checksums, and hands the NIC a specification for DMAing the right header/data pairs onto the wire. The win is fewer trips through the driver API and less per-packet CPU. Critically, TCP flow control stays in the protocol stack — the driver shapes bytes the stack has already decided are legal to send. Correctness still depends on MSS, checksum, and ordering lining up between stack, driver, and NIC, but no full segmentation engine is baked into the hardware.
`US9686117B2` — chimney onload. This integrates the user-level onload stack with OS-level offload concepts. Functions normally performed by the kernel network stack can run in user-level code while preserving the kernel's view of state where it is needed. It explicitly contrasts conventional OS TCP/IP — where the OS performs the stateful work of retransmission, segmentation/reassembly, flow control, and congestion avoidance — with the user-level architecture, the same recurring boundary: accelerate the path, keep the authority coherent.
`US8743877B2` — programmable header-processing engine. Header manipulation is the most repetitive packet work of all, and a programmable engine lets it be expressed and changed without hardwiring one fixed format into silicon. That programmability is the bridge between “fixed-function NIC offload” and the later programmable-data-plane direction the team took.
`US8996644B2` — encapsulated accelerator. A NIC controller steers packets to an accelerator module — an FPGA or custom block — that appears as one or more network endpoints, addressable over UDP/IP or Ethernet. Tractable offloads such as TCP/IP checksums, iSCSI CRC digests, hashing, lookup, and flow steering stay as clean hardware functions, while custom logic sits beside the commodity NIC datapath rather than replacing it — you keep the high-performance commodity NIC and attach bespoke processing where it earns its keep.
Why it matters. The unifying tradeoff is that none of these require full TCP in hardware. Each pushes a repetitive, well-bounded piece of work — message parsing, segment shaping, header rewriting, fixed-function offload — toward the device, while flow control, ordering, and transport correctness stay in software that can validate, fall back, and evolve. The interview-relevant judgement is knowing which work is safe to push: it has to be repetitive, bounded, and cheaply reversible or verifiable, so the host can always be the authority that says yes or no after the fact.
Sources