🗣️ The interview playbook

Turn the patent canon into talking points, smart questions, and an honest bridge from your own background.

9.1 Talking points & questions

The rule before any of these come out of your mouth. Every line below is framed as something you read in the public patent record and want the interviewer's read on — never as a claim about AMD's internal roadmap, structure, or what the product does today. The patents are years old; say what they reveal about the team's worldview, ask an open question, and listen. Pick two or three for a 30-minute call.

Frame kernel bypass as cost-reduction plus isolation, not "the kernel is bad." The patents are careful here, and so should you be. Onload reads as host TCP/IP kept in user space, with the NIC providing fast queues and the hardware enforcing what each queue is allowed to send — explicitly not a full TCP-offload engine (US8489761B2), with the OS still able to recover buffers and step in when an app is descheduled or dies (US8612536B2). The question: "My reading is that the design bias has always been to keep TCP correctness and recovery in trusted software and use the NIC as a guarded fast queue, rather than freezing a transport state machine into silicon. Is that still the way the team thinks about where logic should live?"

Show you know latency is not just syscalls. A naive pitch says "kernel bypass removes the syscall, done." The portfolio says the harder wins are elsewhere: per-core socket state to kill lock contention and cache-line bouncing (US9304825B2), and treating descriptor/completion PCIe traffic as a latency cost in its own right (US7831749B2). The question: "Once the kernel is off the hot path, where does the next slice of tail latency actually come from — cache movement and per-core state, the steering/filter lookup, or the NIC pipeline and PCIe round-trips? How do you tell them apart when you profile?"

TX PIO vs DMA, and the CTPIO cut-through threshold. This is a concrete, mechanism-level talking point. Small latency-sensitive sends can go via programmed I/O — the CPU stores packet bytes straight into a NIC buffer and rings a doorbell, skipping descriptor-fetch latency (US10394751B2) — and cut-through PIO starts transmitting before the whole frame has arrived, deliberately corrupting the FCS if the source underruns so the receiver drops it (US11044183B2, with a per-queue start-threshold knob added in US11165683B2). The question: "The cut-through threshold looks like a direct latency-versus-underrun-probability trade. How is that threshold actually chosen for a given workload — is it static per queue, or does anything adapt it?"

Freshness versus delivery — where should that policy live? One patent drops a packet whose deadline has passed rather than send it late (US9391840B2). That encodes a real opinion: for some workloads stale data is worse than no data. The question: "The 'avoid delayed data' idea says reliability is workload-dependent — for a trading feed, freshness can beat delivery. Where do you think that deadline policy belongs: in the application, the user-space stack, the driver, or the NIC? It seems like it could sit at several layers."

The host/device TCP split — what invariants must the host keep? The selective-offload patents hand enough state to the device for selected streams (sequence numbers, checksum, ACK, bounded transmit) while keeping reorder, retransmit, and congestion control in host software (US9674318B2, US10873613B2). The question: "When you push part of TCP toward the device for a hot stream, which invariants does the host have to retain to stay correct — and how do you claw a connection back to pure software if the fast path can't handle what arrives?"

The SmartNIC/DPU shift — how much is still ultra-low-latency host networking? The same inventors now appear on programmable-data-plane patents: FPGA kernels inserted into the RX/TX path (US12445395B2), zoned multi-tenant DPUs (US11983133B2), and line-rate traffic management (US11743134B2). The question: "Publicly the lineage moves from user-space TCP toward a programmable DPU — FPGA in the path, traffic management, tenant isolation. From the engineering side, how much of the work is still the ultra-low-latency host-NIC problem versus turning the NIC into a managed cloud-infrastructure device? I'd want to know which of those a new engineer ramps into first."

Sources

9.2 Bridging your CV

Start by naming the gap, then claim the substrate. You have not shipped a Linux Ethernet NIC driver, and the strongest version of you says that out loud before anyone forces it. The honest pitch is not "wireless is basically Ethernet" — it is "same engineering discipline, adjacent domain." These patents obsess over a short list of concerns: descriptor rings and DMA, doorbells and MMIO, interrupt-versus-poll timing and jitter, hardware-visible state and ownership, a constrained-C hot path, and cross-layer debugging. You have touched most of those objects already — in a different protocol domain. That is the bridge.

Descriptor rings and DMA — you have programmed this engine, just not on Ethernet. The portfolio treats the descriptor ring as the central datapath object: queue-empty folded into completion events to cut control-plane PCIe traffic (US7831749B2), DMA descriptor caching and write-pointer management (US7496699B2). Your AXI-DMA work is the same shape — you set up descriptors, hand a buffer to a DMA engine, and reclaim it on completion. The honest bridge: "I haven't driven a NIC RX/TX ring, but I've programmed AXI-DMA descriptors and lived with the same lifecycle — fill the descriptor, transfer ownership to hardware, get a completion, recycle the buffer. The nouns change from AXI to PCIe; the ownership problem doesn't."

Doorbells and MMIO — the publish-and-ring pattern is familiar. TX PIO is literally a CPU store to an uncached NIC buffer followed by a doorbell write (US10394751B2). In firmware you've done exactly this class of thing: write a control register over a memory-mapped bus and make sure the device sees your data before it sees the kick. The honest bridge: "The descriptor-then-doorbell sequence — fill the slot, make the writes visible, ring the MMIO doorbell, then let the device fetch — maps directly onto register/doorbell programming I've done at the PHY boundary. I know volatile is about the compiler, not a memory-ordering guarantee; the visibility comes from barriers and the bus model."

ISR timing — you've lived interrupt-vs-poll and jitter for real. The team cares deeply about jitter: timestamp at the PCS/MAC before elastic buffers and interrupts add noise (US10742782B2), and busy-poll-before-block rather than always taking the interrupt (US9384071B2). Your DSP interrupt-service-routine timing work is the same trade under a hard deadline. The honest bridge: "I've owned ISR-timing budgets where an interrupt that arrives a few microseconds late breaks a frame. The interrupt-versus-poll decision, and the fact that the interrupt path itself is a jitter source you sometimes design out by polling, is something I've reasoned about under real timing pressure — just on a DSP rather than a NIC."

Hardware-visible state and ownership — this is the core of your transferable story. The whole isolation story is about who is allowed to touch what, enforced in hardware (US7634584B2). Your 5G TX-channel arbiter is, at heart, an ownership-and-timing problem: who gets the channel, when, and what state has to be visible and consistent at the handoff. The honest bridge: "My arbiter and BSRP/DFE work was about ownership of a shared resource and proving state was consistent at every handoff under a deadline. Descriptor-ring ownership and the host/device TCP split — host keeps reorder and retransmit, device gets bounded TX state — is the same kind of question in a different domain (US9674318B2)."

Constrained-C hot path and cross-layer debug — already your day job. You ship production C where the hot path is counted in cycles and bugs cross the firmware/RF/calibration boundary — the same muscle as debugging a p99 latency spike or a packet drop across the driver/firmware/NIC line. The honest bridge: "Spec-to-C, a constrained hot path, and debugging across the hardware/software boundary — instrument the handoff points, separate facts from assumptions, trace one path end to end before changing anything — is exactly how I'd approach a NIC datapath bug. The protocol is new to me; the method isn't."

Two clean sentences you can actually say. "My strongest background is production C at the hardware/software boundary — descriptor/DMA-style accelerator programming, ISR timing, ownership of shared hardware state, and cross-layer debugging under release pressure. I haven't shipped a Linux NIC driver, so I'd be learning the Ethernet datapath and the netdev/Onload specifics, but the engineering discipline these patents are built on — bound the hot path, prove visibility, define ownership, instrument the boundary — is the work I already do."

Sources