🧭 The team & the thesis
Who builds the fast path, why their patents are the clearest window into the work, and how to read your interviewer.
1.1 Who builds the fast path
The team you are interviewing with has a long lineage that predates AMD by two decades. It started as Level 5 Networks and Solarflare Communications in Cambridge, England — a group building high-performance Ethernet NICs and the user-space networking software that made them fast. Xilinx acquired Solarflare in 2019, folding that NIC expertise into its FPGA and adaptive-SoC world. Then AMD acquired Xilinx in February 2022, and the same Cambridge engineers now sit inside AMD's networking organization. When you read a patent in this book, watch the assignee field tell that story: a 2007 filing is assigned to Solarflare, but Google Patents shows the current assignee as Xilinx — the IP followed the team through every acquisition.
The clearest way to understand what this team actually does is to read who keeps signing the patents. Two names appear on the vast majority of the networking work: Steven L. Pope and David J. Riddoch. They are the patent engine. From the foundational Onload patent (US8489761B2, filed 2007) through to recent SmartNIC/DPU filings granted in 2024 and 2025, Pope and Riddoch are named together over and over. If you internalize their patents, you have internalized the team's technical worldview. Around them orbits a stable cast of recurring co-inventors: Kieran Mansley (latency, event ordering), Derek Roberts and Ching Yu (early DMA and receive-filtering hardware), and Dmitri Kitariev (header processing, programmed I/O). The newest DPU work adds Jaideep Dastidar for heterogeneous SoC integration.
Across roughly forty verified patents, one idea unifies almost all of them, and it is worth memorizing as a single sentence:
Move the per-packet hot path out of the kernel and as close to the application and the NIC as possible — but keep correctness, isolation, and control in trusted software.
That sentence is doing a lot of work, and every clause matters. Hot path out of the kernel is kernel bypass: a user-space socket library forms packets in the application's own context and drives NIC queues directly, skipping the syscall, copy, interrupt, and cache-pollution costs that the conventional Linux path pays on every operation. Close to the app and the NIC is the ef_vi raw datapath, programmed I/O, message templates, and FPGA kernels in the receive/transmit pipeline. But the second half is what makes the design shippable rather than reckless. Correctness means TCP retransmission, reordering, and congestion control stay anchored in host software. Isolation means the NIC hardware validates that a user-space queue is only allowed to transmit the traffic it was authorized for, so an untrusted process cannot spoof. Control means the kernel can always recover resources if an application dies, and routing decisions still match system policy.
Crucially, this is a deliberate rejection of the full TCP-offload engine (TOE). The team does not try to hide an entire TCP stack inside the NIC. They split the datapath instead: latency-critical, common-case work moves down toward hardware, while the messy, correctness-heavy, rarely-hot work stays up in software where it can be debugged, patched, and policed. The rest of this book is the same thesis told seven more times — through kernel bypass, the ef_vi transmit path, safe direct access, receive steering, selective offload, timestamping, and finally the turn toward the programmable DPU.
Sources
1.2 Why read their patents
Marketing pages tell you what a product does. Documentation tells you how to use it. Neither tells you how the engineers who built it actually think — what tradeoffs kept them up at night, which problems they considered hard enough to be worth protecting, and where they drew the line between software flexibility and hardware speed. A patent portfolio does. A granted patent is a dated, signed record of a specific engineering decision, written in enough detail to defend in court, naming the exact people who made it. Read forty of them from the same team and the recurring concerns stop looking like coincidence and start looking like a worldview.
For this team, that worldview is a single design pattern repeated at every layer: split the datapath. You will see it so often it becomes predictable. Kernel bypass splits socket work between a user-space fast path and a kernel control plane that can still recover resources (US8612536B2). The dual-driver interface splits a fast data channel from a privileged control channel (US8855137B2). Selective TCP offload splits transport processing so the host keeps reordering and retransmission while the device handles the common case (US9674318B2). Safe direct access splits authority — trusted software configures what a queue may do at setup, and the NIC hardware enforces it on the hot path (US8380882B2). Even the DPU work splits a chip into isolated zones. Once you see the pattern, you can predict roughly how this team would solve a new problem: find the latency-critical common case, push it down toward the hardware, and leave a trusted-software backstop for correctness, recovery, and the rare path. That predictive power is exactly what makes the portfolio worth reading before an interview — it lets you reason about questions you have never seen, the way the team would.
A patent reading also calibrates your vocabulary. These are the people who care that control-plane PCIe traffic is itself a latency cost, not just packet data (US7831749B2); that cache placement and NUMA locality matter as much as avoiding syscalls; that event ordering across many polled sockets is a real problem. Walking in fluent in those concerns signals that you understand the domain at the level they work at.
Now the honest caveat, because it matters more in an interview than anywhere else. Every patent number, inventor name, and link in this book came from web search, assembled by automated research threads reading Google Patents. Web search is good but not infallible: it can transcribe a digit wrong, conflate two filings, or surface a continuation under a slightly different number. So before you quote a specific patent number out loud — "your US8489761 patent" — click the link and confirm it. The links here are real Google Patents URLs precisely so you can verify in thirty seconds. And never, ever imply inside knowledge. You did not work on these patents; you read the public record. The right framing is always "I went and read your team's public patents and noticed a pattern," never "I know that you do X." The former is impressive diligence. The latter is a claim you cannot back up, and a sharp interviewer will catch it instantly. Use the portfolio to ask better questions, not to pretend you already know the answers.
Sources
1.3 Miklos Reiter, specifically
A word of warning before you over-prepare on patents: your interviewer, Miklos Reiter, is not a named inventor on any of them. Searches that seemed to put a "Miklos Reiter" on Solarflare filings were false positives — different people, or mismatched records. The patent engine is Pope and Riddoch, not Miklos. If you walk in and try to impress him by reciting his patent claims, you will be reciting work he did not do, and the conversation will go sideways fast. Read the portfolio to understand the team; do not mistake it for understanding the man.
His real signal is a different and arguably more interesting one. Miklos is a software leader, not a hardware patent author. The clearest public marker is that he led the Solarflare Cloud Onload Operator — the piece that brings Onload acceleration into Kubernetes and OpenShift. That tells you a lot. It means his daily problems are productization and operability: how do you take a low-latency NIC technology that grew up in single-tenant trading systems and make it deployable, manageable, and safe inside an orchestrated, multi-tenant cloud platform? That is a world of operators, custom resources, lifecycle management, tenant isolation, and "does this actually work when an ops team who has never heard of ef_vi deploys it at 2am" — not a world of descriptor-ring micro-optimizations.
Behind the software leadership sits a serious quantitative background. Miklos holds a Cambridge PhD (2007) in what is effectively operations research and economics applied to networks. His thesis is Internet Congestion Pricing: Long-Term Bandwidth Contracts and Investment in Oligopoly. He published with Richard Steinberg at INFOCOM 2010 ("Forward Contracts for Complementary Segments of a Communication Network") and in IEEE/ACM Transactions on Networking in 2012 ("Congestion-Dependent Pricing and Forward Contracts for Complementary Segments of a Communication Network"). So the lens he brings to networking is congestion, resource allocation, pricing, and incentives — how a scarce shared resource gets allocated under contention, and what tradeoffs that forces. He thinks in terms of systems and markets, not silicon and FCS bits.
Put those two halves together and you get a coherent picture of who is across the table: someone who thinks about congestion and resource allocation (the PhD), productization and operator experience (the Cloud Onload Operator), and the tradeoffs between latency, isolation, manageability, and cost. He will probably not quiz you on the exact wiring of a cut-through-PIO underrun. He is more likely to care whether you can reason clearly about a system under contention, whether you understand why isolation and operability matter once you leave the single-tenant trading box, and whether you are someone who can be handed an ambiguous problem and a team.
So pitch yourself accordingly. Lead with clear systems reasoning and a feel for tradeoffs under contention — show you can talk about where a policy should live (app, user stack, driver, or NIC) and why, not just that you can name a patent. Connect your embedded and wireless-PHY background to concerns, not just code: queue ownership, backpressure, scheduling under load, the hardware/software boundary. Show genuine, verified curiosity about the team's public work — "I read your patents and noticed they deliberately avoid a full TOE; how does that bias hold up in the cloud-operator world you've been building for?" is a perfect Miklos question. It engages his actual domain, demonstrates you did the homework, and presumes nothing.
Sources