If you follow Intel and the nuggets of information it releases regarding progress on its processors, you might be familiar with its DPDK (Data Plane Development Kit). The idea behind the DPDK is to enable bypass of software-based network stacks and allow access directly to the data plane, enabling a nearly zero-copy environment from network to CPU. Without getting too deep in the weeds, the ability to bypass the OS processing that forwards packets through a system is a lot like what network manufacturers have done for years – enabling direct access to hardware, which results in much higher performance.
This brings to mind one of the arguments for (and against) certain hypervisor implementations. Those that are paravirtualized require a modified version of the operating system, which can be off-putting to some customers. In much the same way, applications desiring to take advantage of Intel’s DPDK will need a modified version of the operating system that includes the necessary drivers and libraries.
Not an insurmountable requirement, by any stretch of the imagination, but one that should be taken into consideration nonetheless as the performance gains of having (more) direct access to bare metal is considered worth it, particularly for networking-oriented applications.
How much gain? Errata Security claims a 100 to 1 difference, while Intel has claimed even higher gains:
You might be skeptical at this point, especially if you’ve benchmarked a commodity Intel x86 system recently. They come nowhere near network wirespeeds. The problem here isn’t the hardware, but the software. The network stack in today’s operating systems is painfully slow, incurring thousands of clock cycles of overhead. This overhead is unnecessary. Custom drivers (like PF_RING or DPDK) incur nearly zero cycles of overhead. Even the simple overhead of 100 cycles for reading the packet from memory into the CPU cache is avoided.
A standard Linux system that struggles at forwarding 500,000 packets-per-second can forward packets at a rate a 50 million packets-per-second using these custom drivers. Intel has the benchmarks to prove this. This is a 100 to 1 performance difference, an unbelievable number until you start testing it yourself.
— Errata Security: Software networks: commodity x86 vs. network processors
The (POTENTIAL) IMPACT on CLOUD
While the Intel DPDK is easily interpreted as a boon for SDN and network virtualization proponents as well as telecommunications, the question as to how the Intel DPDK will interact with virtualization technology must be asked because of its potential impact on cloud. The premise of virtualization implies a layer of abstraction between the hardware and applications deployed within the environment, the purpose being to allow sharing of hardware. This runs counter to the premise of DPDK, which is to bypass such intervening software and allow direct access to the hardware. Cloud, which is almost universally built atop some form of virtualization technology, seems inherently incompatible then with Intel’s DPDK. It turns out it is, with some minor modifications.
A recent post by Scott Lowe explains.
To help with intra-VM communication, Intel DPDK offers several benefits. First, DPDK provides optimized pass-through support. Second, DPDK offers SR-IOV support and allows L2 switching in hardware on Intel’s network interface cards (estimated to be 5-6x more performant than the soft switch). Third, DPDK provides optimized vNIC drivers for Xen, KVM, and VMware. [emphasis added]
What Intel has been working on is repliace [sic] the VirtIO drivers with DPDK-enabled VirtIO drivers, and use DPDK to replace the Linux bridging utilities with a DPDK-enabled forwarding application. The DPDK-enabled forwarding application is a “zero copy” operation, thus reducing latency and processing load when forwarding packets. Intel is also creating shims between DPDK and Open vSwitch, so that an OVS controller can update Open vSwitch, which can then update the DPDK forwarding app to modify or manipulate forwarding tables.
The former resolves the issue of sharing hardware (and likely produces fewer performance gains than having sole access but should still see improvement) and the latter addresses what would become another bottleneck if the former is implemented, the virtual switch.
Ultimately, however, what such modifications do is introduce dependence on specific hardware resources in order to accommodate a very real need – performance.Not all hardware is capable of supporting DPDK – it is Intel specific, after all – which means careful attention to hardware capabilities would be required in order to manage myriad workload types in a cloud computing environment. In a cloud environment, built on the premise of commoditized and broadly applicable hardware and software this has the effect of reversing commoditization.
Cloud’s benefits of efficiency and lower costs are highly dependent on the ability to leverage commoditized hardware, available for repurposing across a wide variety of workload types. The introduction of hardware and images specifically designed to enable DPDK-capable services would complicate the provisioning process and threaten to decrease efficiency while increasing costs.
Cloud could still benefit from such progress, however, if providers take advantage of DPDK-enabled network appliances to build its underlying infrastructure – its support foundations. Without the pressures of seemingly random provisioning requirements and with a more controlled environment, providers could certainly benefit from improved performance that might allow consolidation or higher throughput. This could become a selling point, a differentiator, to the market for a cloud to be built on the premise of "bare metal access" and its performance enhancing characteristics.
Given the right impetus, they might also find a premium cloud service market hungry for the performance gains and more importantly, willing to pay for it.