Specialty hardware vendor Napatech is working on a network interface card (NIC) that it hopes can solidify network functions virtualization (NFV) performance. Specifically, the company aims to get one CPU core to handle a full 40-Gb/s payload under any circumstances.

The NIC has progressed far enough that Napatech was able to display the hardware at Mobile World Congress last week. Its active ingredient is a line-rate packet-processing pipeline that runs on FPGAs. The idea is to offload processing from the CPU, so that you no longer need multiple cores to get to 40 Gb/s.

When it comes to the NIC's software, however, Napatech is screening its customers as to which features should be included. The company is moving deliberately, because the NFV NIC represents a new business model: It would be Napatech's first general-purpose product, after more than a decade of producing NICs for specific tasks such as accelerating network management or security.

“We're used to selling thousands of units a year. With this, you're talking millions per year,” says Dan Joe Barry, Napatech's vice president of positioning and its chief evangelist. “We want to launch this year. We want to make sure that when we do, we've reached a consensus on what's useful.”

The plan is to have commercial prototypes ready by April, with general availability sometime this year.

Based in Denmark, Napatech has been offering acceleration hardware for 13 years. Its customers include appliance vendors that needed to adapt to NFV, and their concerns about the performance of virtualized network functions (VNFs) led to the creation of the NFV NIC.

Napatech first wanted to build a specialty NIC that would accelerate OVS in particular servers, but the idea sank. Carriers didn't want a special NFV Zone. They wanted data centers full of uniform, commoditized servers — the model of the hyperscale players.

“At Mobile World Congress last year, we got a clear message from some of the NFV vendors: If your stuff's going to work, it's got to be in every server,” says Barry.

NFV performance isn't always an issue, but it does tend to arise when dealing with small packet sizes — and small packets happen more frequently when voice and video traffic are being processed. In September, Intel released a benchmark report showing that in a worst-case scenario involving 64-byte packets and off-the-shelf NICs, it can take several CPU cores to reach 40-Gb/s.

One issue is that most NICs are general-purpose products that aren't engineered for traffic throughput, Barry says. “You sell millions of those things every year for all sorts of uses, and you don't need full capacity in 90 percent of them.”

NFV is different — it's going to be handling functions that do need full line rate. So Napatech built the NFV NIC to be a throughput monster, loaded with high-end FPGAs. It's running a packet-processing pipeline engineered to keep up with line rate. The hope is to offload some of the tasks that eat into CPU cycles.

Plenty of others are working on NFV performance. Intel has open-sourced its Data Plane Developer Kit (DPDK), which companies including 6WIND and Wind River (an Intel subsidiary) have taken advantage of. And the crew working on Open vSwitch, an open source project that's landed under the ownership of VMware, has been working on performance improvements as well.

One well accepted approach has been single root I/O virtualization (SR-IOV), which connects VNFs directly to the NIC, bypassing the virtual switch. This can help, because communications between the CPU and virtual switch are one of the reasons NFV performance might suffer.

But the price is a loss of mobility, as it would be difficult to migrate a VNF to a different server. “It's not impossible to move these things, but it's pretty hard,” says Barry.

Because the NFV NIC uses FPGAs, it could be programmable on the fly. That is, the FPGAs could adjust to different types of VNFs that pop into existence. A particular VNF could load look up tables into the FPGAs, for instance, possibly increasing the OVS switching throughput even further.

Making this work would require more sophisticated management and orchestration. It's something some customers are already talking about doing, but not something Napatech would directly get involved in, according to Barry.