Network interface cards (NICs) have been on the market since shortly after the first PCs in the mid-1980s. However, over the past few years, we’ve seen the emergence of SmartNICs. Each company in this market has a different definition of the SmartNIC product segment.
The most basic definition is as simple as a NIC that’s programmable. Conversely, others have overloaded the concept by heaping vast amounts of silicon and firmware into their implementations. At the end of the day, though, the typical answer is a NIC that includes additional, available, computational resources that are exposed to the customer, along with the necessary open-source tools to utilize those resources.
Many people had mobile phones when smartphones hit the scene, yet a decade later, nearly all mobile phones are smartphones. Why is that? It isn’t because people got tired of “Snake” and wanted to move to “Candy Crush.” They saw the value of having a fully programmable phone, camera, and mobile computing platform on which they could manage social media, stay connected via email to the office, and do a host of things nobody envisioned a decade ago.
The vast majority of smartphone users will never write a line of code, and they don’t have to—tens of millions of applications are already available for them to choose from in the App Store. Server NICs will follow a much similar, yet shorter, path into becoming SmartNICs.
Having a SmartNIC is pointless if you can’t make it do something other than just pass packets. To be a SmartNIC, you need additional computational resources that are unassigned, and for which code space exists to leverage these resources.
In 2002, 3Com put out a 10-/100-Mb/s Ethernet NIC that included a firewall. It used the company’s 3XP processor and had additional memory to pull off this task. This was nearly 20 years ago, and Gigabit Ethernet adoption already started ramping up. Still, the processor and memory were fully committed to the firewall application, so it was a dedicated security point product and not a SmartNIC.
Had 3Com opened up the programming interface and sold a version without the firewall, it would have been the first SmartNIC. The company also would have been two decades early to the party, plus 10-/100-Mb/s networks were already on the backside of the adoption curve, which is never where a new product should be. Finally, the 3XP as a processor was likely too underpowered to handle 1 GbE, so it was probably a good idea for them to exit at that point. Today, table stakes for a data-center NIC are 25 GbE with scalability in the product line to 100 GbE.
Bumping Up the Computing Power
With data-center networking today at 25 GbE and rapidly moving to 50 GbE and 100 GbE, additional computational resources on a SmartNIC need to be carefully considered. The conventional wisdom is that traditional CPU cores like those from Arm should be reserved for control-plane management and, in rare cases, exception flow processing. Control-plane management is like saying that the Arm cores make for good police sergeants, but horrible traffic cops.
Data-center NICs today handle millions and potentially more than one hundred million network packets per second. Arm cores, even those clocked at 3 GHz, aren’t up to the task of inspecting and acting upon millions, or worse yet, tens of millions of packets per second each. There aren’t enough instructions per second to keep up with these volumes. Special purpose computational resources like dedicated network processors, field-programmable gate arrays (FPGAs), or perhaps GPU cores are needed to process these volumes.
In this space, FPGAs, because they’re programmable logic, are best suited for the task. They can be configured to parse the network packet header rapidly, or even the body, and then take the necessary action from dropping the packet to wrapping it or changing the contents entirely at line-rate. An excellent example of an FPGA-based SmartNIC that also includes an Arm complex and a network processor is Xilinx’s Alveo U25 card. So, while some SmartNICs may claim they expose Arm cores to process traffic flows, one should consider the potential volumes involved and do the math.
The next big issue is making the programming interface to the SmartNIC publicly available. As we said above, it’s the availability of applications that made the smartphone a success. When Myricom debuted its Myrinet 10G line of networking products to the public at SuperComputing 2005, it could have called its first-generation 10-GbE product a SmartNIC.
At the time, the Lanai10G chip that powered Myricom’s NIC was a network processor, with firmware space in flash for programming and high-speed SDRAM for data storage. That Myrinet-10G NIC supported three modes of operation: 10-Gb Ethernet, Myrinet-10G, or Myrinet Express over Ethernet (MXoE). Over the next few years, firmware was added to support line-rate capture, acceleration of storage packets, and acceleration for trading. The reason this doesn’t fit our SmartNIC definition is that the programming environment was never exposed for external adoption. Myricom had several valid reasons for this—it was a ‘C’ like language, it was hard to write in, and even harder to debug—but these reasons no longer matter.
Some might say that Tilera’s product was the first performance SmartNIC, but that argument also fails because the company refused to make the programming interface and tools publicly available. In the spring of 2013, Tilera (what would later become Mellanox Bluefield) was adamant about charging for access to the programming environment for its SmartNIC, and for the classes required to understand how to use it. Therefore, adoption was minimal, application development crippled, and market acceptance was nearly zero.
A hardware platform that charges developers for access is doomed to limited success at best. With the widespread adoption of open-source software and repositories like GitHub, developers expect the tools to be free.
Build an App Store
Finally, for SmartNICs to become wildly successful, they need a centralized repository for SmartNIC applications, an App Store. One where independent third-party application developers can submit their code and be compensated when it’s installed or executed. This catalog is then curated, published, and made readily available to users.
Without an App Store, users will be required to purchase apps from the NIC providers or hunt down and purchase the applications from third-party suppliers. Imagine if you had to buy every app for your smartphone from third-party websites? How successful would that model have been? Not very.
We see a new generation of SmartNICs from companies like Broadcom, Intel, Mellanox, and Xilinx that utilize a wide array of computing resources. These companies are finally catching on as they release programming tools for their environments, and third parties are beginning to program for their platforms.
Scott Schweitzer is Technology Evangelist at Xilinx.