NFV topics sparked interesting discussions this month regarding performance and scale. Starting with the NFV World Congress in San Jose, the “pets-versus-cattle” analogy took new angles when Toby Ford, AT&T’s VP for Cloud Strategy, coined the term “midget cattle” and proclaimed that virtual network functions (VNFs) should not be huge like cattle and, by the way, should not take up all of the memory of a host.

Then Dell’Oro VP Shin Umeda proclaimed in a report that some very large NFV projects will start ramping in the next 12 months. As with any large scale or live deployment, performance is a key requirement, and performance was a resounding theme in nearly all of the speeches at NFV World Congress.

Performance continues to fuel the NFV discussion because without proper oversight, virtual machines and cloud infrastructure can be real headaches by demanding increasing requirements of hardware to accommodate an increasing software footprint. When transitioning to NFV, there are many performance bottlenecks to consider.

In the NFV Infrastructure, additional software layers increase performance bottlenecks that can negate any cost savings and flexibility promised by NFV. There is the driver-level bottleneck due to the Linux kernel, the virtual switch bottleneck in standard virtual infrastructure including Open vSwitch (OVS), and the communication bottleneck between host and guest performance.

Starting with the driver-level bottleneck, DPDK (data plane development kit) is a key technology to bypass the Linux kernel and give access to run traffic in the user space. The DPDK.org open source project exists to fuel community oriented progress with a framework for fast packet processing. However, DPDK is not a networking stack – it's a packet pump. A complete and high performance networking stack will need to leverage DPDK for the best performance.

Regarding the virtual switch bottleneck, the community is working on an open source project called OVS-DPDK. OVS 2.4 will include DPDK for the first time, however OVS-DPDK is still a PoC showing that data plane acceleration is possible for the OVS component. This integration shows that acceleration through DPDK only is not enough, and an entire stack needs to be built on top of DPDK to support different features needed in NFV. Considerations for OpenStack and other management as well as SDN controller integration must be carefully planned to not break existing infrastructure. Also, as we saw with the previous OVDK project for OVS and DPDK, open source projects can be discontinued, forked, or take time to complete.

Standard vNIC drivers also have major performance bottlenecks. Virtio is required by NFV solutions because it is a major standard already used by many VMs. Efficient packet processing software should also take care of this host/guest communication bottleneck, while preserving Virtio support.

Commercial vendors exist to solve these NFVI performance challenges quickly, reducing time to market with software packages for the hypervisor domain that include the necessary networking stacks for NFV Infrastructure, and support. When selecting a commercial vendor, transparency is a key requirement so that modifications are not required by Linux, OVS, or OpenStack, and you don’t have to deploy additional engineering resources with each code release.

As you move into the VNF environments, applications become critical as revenue will depend on them. To fuel these applications, accelerating your hypervisor is not enough. If your VNFs are not designed to welcome traffic from your accelerated hypervisor domain leveraging standard virtio interfaces, they will default back to the lowest performance dominator. VNFs should never hide behind the performance of the hypervisor, they must be equally tuned.

VNF vendors have already started to leverage DPDK and integrate performance tuned networking stacks on top for the best performance. With properly accelerated host and guests environments, the VNFs are ready to communicate with each other at a high speed, which is the holy grail of NFV performance.