- Analysts are not employed by SDxCentral.
- Views and opinions expressed in analyst content belong solely to the author and do not reflect the views of SDxCentral, LLC.
- SDxCentral does not fact check analyst content. If you believe there is a factual error in analyst content, please notify [email protected] Should we find factual irregularities, that article will be unpublished from the SDxCentral website.
Effective April 18th, 2019, the SDxCentral analyst blog syndication program has been terminated.
SDxCentral Statement about AvidThink, LLC
- Roy Chua, the founder of AvidThink, was a co-founder of SDxCentral. As of September 30, 2018, Roy is no longer affiliated with SDxCentral.
- The views expressed by AvidThink and Roy Chua are independent of SDxCentral and do not represent the views or journalistic principles of SDxCentral.
- As of April 18th, 2019, SDxCentral is no longer publishing AvidThink analyst blogs on the SDxCentral website.
The Data Plane Development Kit (DPDK) Summit 2018 was held at the Club Auto Sport in San Jose, California, last week, a unique and appropriate location given that DPDK is the engine that powers many NFV platforms today, including auto-focused platforms. As presenters shared the latest research and developments with DPDK in an automobile-themed environment, it was clear that the DPDK initiative’s scope is expanding beyond its original Intel roots. While Intel still has an outsized role within the project, DPDK’s home at the Linux Foundation lends more credibility to its outreach efforts.
For those readers who might still be unfamiliar, DPDK is a set of software libraries designed to accelerate packet-processing workloads running on a wide variety of CPU architectures. Originally developed by Intel, it supports the x86 architecture, obviously, but also works with Arm and IBM Power architectures. In addition, DPDK runs on network interface cards (NICs) from various companies besides Intel, including Broadcom, Mellanox, and Netronome.
To get an update on DPDK, the Linux Foundation arranged a chat with some of the technical and business project leaders. These included Thomas Monjalon from Mellanox — originally with 6WIND — and Bruce Richardson, Jim St. Leger (Chair of the DPDK Board), and Tim O’Driscoll from Intel. I was also able to catch up with Bob Monkman from Arm, who has been successfully driving Arm’s participation in various SDN and NFV initiatives.
DPDK: A Key to the Rise of the Arm Ecosystem
Arm’s performance has been touted by some telcos and equipment providers as potentially more power-efficient than an x86 CPU with the same performance. Phrased another way, getting the same virtual network function (VNF) performance from Arm requires less energy and less spend. Mainstream CPE vendors are now starting to push ARM platforms, and in a recent conversation I had with Telco Systems’ CEO Ariel Efrati, he pointed to promising results for Arm in benchmarking.
Many ODM and OEM CPE manufacturers in Taiwan and China have also accepted Arm into the overall CPE ecosystem. In fact, because of Cavium’s role in many security platforms, ODMs are already very familiar with the solution.
To gain maximum performance from these Arm-based platforms, Arm will need to ensure that DPDK continues to leverage all the capabilities of the platform. It appears that the DPDK team is open to this and embraces the Arm community’s involvement — nice to see collaboration that’s potentially a mutual win.
More Than Acceleration, It’s About API and Abstraction
Looking beyond Arm’s role in DPDK, the larger observation is that DPDK is now less about accelerating NFV, and more about having a uniform API and abstraction layer for core functions important to high-performance I/O and packet processing. DPDK is a Linux user-space framework that now provides an abstraction to more than acceleration. Without going into details, being in a user space makes it easier to use, troubleshoot, and update. Some developers see DPDK as an express lane to getting support for their devices to developers while waiting for the Linux kernel team to approve their changes.
For example, the DPDK Event Device library is an abstraction that provides an application with features to manage events and timers. This event/dev framework provides improved event handling, including supporting hardware timers if they exist, and it reduces potential overhead in polling loops. But the framework unifies support for both polling and event-driving programming models, which provides applications with increased flexibility.
And the DPDK Cryptodev API provides a unified API to manage and provision both hardware and software encryption and cryptographic functions, making it easier for software to run portably across platforms with CPU-based hardware crypto-assist, external crypto hardware, or just software implementations. This generic capability reduces the overhead on the software developers and allows them to avoid hardware dependencies. Cryptodev is important with the move to more IPsec and increased TLS use for increased privacy and security in telco networks.
While DPDK does have its warts, which the team openly admits, it has strong traction across the NFV community and has become the accepted way to provide acceleration and more to NFV workloads. The flexibility and software-centricity of the platform is preferred to other alternatives such as PCI passthrough or SR-IOV. With the number of ecosystem partners now jumping on the bandwagon and the increased diversity of the DPDK device frameworks, it may become the de facto API to underlying hardware capabilities, from packet acceleration to crypto, from timers to compression, and more. And for service providers who need the price/performance improved on both x86 and Arm, as well as the VNF developers who want a single unified abstraction to underlying hardware acceleration, DPDK might just be that one API to rule them all.