It’s easy to get excited about what seems to be a new technology and conclude that it will forever change the way we do things. For example, I’ve seen claims that SmartNICs (also known as Data Processing Units – DPU) will forever change the network.

TL&DR: Of course they won’t.

Before we start discussing the details, it’s worth remembering what a DPU is: it’s another server with its own CPU, memory, and network interface card (NIC) that happens to have PCI hardware that emulates the host interface cards. It might also have dedicated FPGA or ASICs.

Now let’s try to put the current blast of hype in perspective by asking two simple questions:

• Have we seen DPUs before?
• What was their impact at that time?

Of course, we’ve seen DPUs before. Engineers have always tried to offload processing from expensive resources like generic CPU cores to dedicated hardware optimized for a particular task.

The first programmable DPU I’m aware of was the IBM 3705 Communications Controller, announced in March 1972 (2700-series controllers were hard-wired). I also had the dubious privilege of being involved with the IBM 3745 Front End Processors (a fancier name for the same idea) while developing a 3271 emulator. Did Front-End Processors (FEP) change networking? No. The real game-changer was the IBM 3270 family of terminals and controllers, with its ability to do local editing and screen-by-screen data transfers.

Even the early Arpanet used DPUs called Interface Message Processors (IMP). One might claim Arpanet changed networking forever, but it wasn’t the IMPs. IMPs were an early equivalent of Frame Relay switches and provided WAN connectivity. The attached hosts did all the hard work that eventually brought us The Internet¹.

One of the first LAN DPUs also came from IBM – the IBM 3172 Interconnect Controller. Cisco developed another monstrous DPU – the IBM Channel Interface Processor for the Cisco 7500-series routers. These DPUs were nothing more than Network Interface Cards on steroids and added nothing new to the networking technologies or designs.

We’ve seen many other DPU attempts in the days when the CPU cycles were expensive, from reassuringly-expensive software-defined² TCP offload NICs to ridiculously expensive iSCSI adapters that ran the whole TCP/IP stack while presenting the (emulated) registers of a common SCSI adapter to the attached server. Most of that functionality was either integrated into NIC hardware (TCP offload) or migrated back to the host CPU once the CPU cycles became cheaper. Having it available on a DPU made no difference in the long term; it just allowed early adopters to deploy iSCSI.

The idea to offload well-defined functionality to dedicated hardware is not limited to networking. Most personal computers used simple video adapters with shared memory decades ago; today, it’s hard to find one that does not use a Graphic Processing Unit (GPU) – another server with its memory and CPU attached to the PCI bus. Did GPUs change the way we do GUI? Nope. They did enable smoother-running games and reduced battery consumption³ for the rest of us, though.

Something similar will probably happen with the currently overhyped batch of DPUs. Eventually, Smart NICs will be everywhere, we’ll figure out how to use them most efficiently, and a few organizations will do remarkable things like AWS did with their Nitro hypervisor⁴. For most of us, nothing will change apart from our devices being a smidgen faster and using a tad less power.

Or maybe we’re already there: did you know you have a DPU within your mobile phone or tablet? Most WiFi chipsets used on those devices have an ARM CPU with RAM, ROM, and operating system⁵. Did those DPUs change the way we do networking? They might have, but I failed to notice.

Finally, a word of warning: every time you’re offloading complex-enough functionality, you’re creating a distributed system with a plethora of interesting edge cases⁶. Someone will have to deal with that complexity and iron out the wrinkles. Remember how long it took for TCP offload on Linux to work flawlessly?