Blog

In today’s rapidly evolving digital landscape, the demand for high-speed, reliable, and scalable network solutions is greater than ever. Enterprises are constantly seeking ways to optimize their network performance to handle increasingly complex workloads. The integration of the Data Plane Development Kit (DPDK) with Microsoft Azure’s Network Adapter (MANA) is a groundbreaking development in this domain.

Building on our recent user story, “Unleashing Network Performance with Microsoft Azure MANA and DPDK,” this blog post delves deeper into how this integration is revolutionizing network performance for virtual machines on Azure. DPDK’s high-performance packet processing capabilities, combined with MANA’s advanced hardware offloading and acceleration features, enable users to achieve unprecedented levels of throughput and reliability.

In this technical Q&A, Brian Denton Senior Program Manager, at Microsoft Azure Core further illuminates the technical intricacies of DPDK and MANA, including the specific optimizations implemented to ensure seamless compatibility and high performance. He also elaborates on the tools and processes provided by Microsoft to help developers leverage this powerful integration, simplifying the deployment of network functions virtualization (NFV) and other network-centric applications.

1. How does Microsoft’s MANA integrate with DPDK to enhance the packet processing capabilities of virtual machines on Azure, and what specific optimizations are implemented to ensure compatibility and high performance?

[Brian]: MANA is a critical part of our hardware offloading and acceleration effort. The end goal is to maximize workloads in hardware and minimize the host resources needed to service virtual machines. Network Virtual Appliance (NVA) partner products and large customers leverage DPDK to achieve the highest possible network performance in Azure. We are working closely with these partners and customers to ensure their products and services take advantage of DPDK on our new hardware platforms.

2. In what ways does the integration of DPDK with Microsoft’s Azure services improve the scalability and efficiency of network-intensive applications, and what are the measurable impacts on latency and throughput?

[Brian]: Network Virtual Appliances are choke points in customers networks and are often chained together to protect, deliver, and scale applications. Every application in the network path adds processing and latency between the endpoints communicating. Therefore, NVA products are heavily focused on speeds and feeds and designed to be as close to wire-speed as possible. DPDK is the primary tool used by firewalls, WAF, routers, Application Delivery Controllers (ADC), and other networking applications to reduce the impact of their products on network latency. In a virtualized environment, this becomes even more critical.

3. What tools and processes has Microsoft provided for developers to leverage DPDK within the Azure ecosystem, and how does this integration simplify the deployment of network functions virtualization (NFV) and other network-centric applications? 

[Brian]: We provide documentation on running testpmd in Azure: https://aka.ms/manadpdk. Most NVA products are on older LTS Linux kernels and require backporting kernel drivers, so having a working starting point is crucial for integrating DPDK application with new Azure hardware.

4. How does DPDK integrate with the MANA hardware and software, especially considering the need for stable forward-compatible device drivers in Windows and Linux?

[Brian]: The push for hardware acceleration in a virtualized environment comes with the drawback that I/O devices are exposed to the virtual machine guests through SR-IOV. Introducing the next generation of network card often requires the adoption of new network drivers in the guest. For DPDK, this depends on the Linux kernel which may not have drivers available for new hardware, especially in older long-term support versions of Linux distros. Our goal with the MANA driver is to have a common, long-lived driver interface that will be compatible with future networking hardware in Azure. This means that DPDK applications will be forward-compatible and long-lived in Azure.

5. What steps were taken to ensure DPDK’s compatibility with both Mellanox and MANA NICs in Azure environments?

[Brian]: We introduced SR-IOV through Accelerated Networking early 2018 with the Mellanox ConnectX-3 card. Since then, we’ve added ConnectX-4 Lx, ConnectX-5, and now the Microsoft Azure Network Adapter (MANA). All these network cards still exist in the Azure fleet, and we will continue to support DPDK products leveraging Azure hardware. The introduction of new hardware does not impact the functionality of prior generations of hardware, so it’s a matter of ensuring new hardware and drivers are supported and tested prior to release.

6. How does DPDK contribute to the optimization of TCP/IP performance and VM network throughput in Azure?

[Brian]: See answer to #2. DPDK is necessary to maximize network performance for applications in Azure, especially for latency sensitive applications and heavy network processing.

7. How does DPDK interact with different operating systems supported by Azure MANA, particularly with the requirement of updating kernels in Linux distros for RDMA/InfiniBand support?

[Brian]: DPDK applications require a combination of supported kernel and user space drivers including both Ethernet and RDMA/InfiniBand. Therefore, the underlying Linux kernel must include MANA drivers to support DPDK. The latest versions of Red Hat and Ubuntu support both the Ethernet and InfiniBand Linux kernel drivers required for DPDK.

8. Can you provide some examples or case studies of real-world deployments where DPDK has been used effectively with Azure MANA?

[Brian]: DPDK applications in Azure are primarily firewall, network security, routing, and ADC products provided by our third-party Network Virtual Appliance (NVA) partners through the Marketplace.  With our most recent Azure Boost preview running on MANA, we’ve seen additional interest by some of our large customers in integrating DPDK into their own proprietary services.

9. How do users typically manage the balance between using the hypervisor’s virtual switch and DPDK for network connectivity in scenarios where the operating system doesn’t support MANA?

[Brian]: In the case where the guest does not have the appropriate network drivers for the VF, the netvsc driver will automatically forward traffic to the software vmbus. The DPDK application developer needs to ensure that they support the netvsc PMD to make this work.

10.What future enhancements or features are being considered for DPDK in the context of Azure MANA, especially with ongoing updates and improvements in Azure’s cloud networking technology?

[Brian]: The supported feature list is published in the DPDK documentation: 1. Overview of Networking Drivers — Data Plane Development Kit 24.03.0-rc4 documentation (dpdk.org). We will release with the current set of features and get feedback from partners and customers on demand for any new features.

11. How does Microsoft plan to address the evolving needs of network performance and scalability in Azure with the continued development of DPDK and MANA?

[Brian]: We are focused on hardware acceleration to drive the future performance and scalability in Azure. DPDK is critical for the most demanding networking customers and we will continue to ensure that it’s supported on the next generations of hardware in Azure.

12. How does Microsoft support the community and provide documentation regarding the use of DPDK with Azure MANA, especially for new users or those transitioning from other systems?

[Brian]: Feature documentation is generated out of the codebase and results in the following:

• Overview of Networking Drivers — Data Plane Development Kit 24.03.0-rc4 documentation (dpdk.org)
• 36. MANA poll mode driver library — Data Plane Development Kit 24.03.0-rc4 documentation (dpdk.org)
• 42. Netvsc poll mode driver — Data Plane Development Kit 24.03.0-rc4 documentation (dpdk.org)

Documentation for MANA DPDK, including running testpmd, can be found here: https://aka.ms/manadpdk

13. Are there specific resources or training modules that focus on the effective use of DPDK in Azure MANA environments?

[Brian]: We do not have specific training resources for customers to use DPDK in Azure, but that’s a good idea. Typically, DPDK is used by key partners and large customers that work directly with our development teams.

14. Will MANA provide functionality for starting and stopping queues?

[Brian]: TBD. What’s the use case and have you seen a need for this? Customers will be able to change the number of queues, but I will have to find out whether they can be stopped/started individually.

15. Is live configuration of Receive Side Scaling (RSS) possible with MANA?

[Brian]: Yes. RSS is supported by MANA.

16. Does MANA support jumbo frames?

[Brian]: Jumbo frames and MTU size tuning are available as of DPDK 24.03 and rdma-core v49.1

17. Will Large Receive Offload (LRO) and TCP Segmentation Offload (TSO) be enabled with MANA?

[Brian]: LRO in hardware (also referred to as Receive Segment Coalescing) is not supported (software should work fine)

18. Are there specific flow offloads that MANA will implement? If so, which ones?

[Brian]: MANA does not initially support DPDK flows. We will evaluate the need as customers request it.

19. How is low migration downtime achieved with DPDK?

[Brian]: This is a matter of reducing the amount of downtime during servicing events and supporting hotplugging. Applications will need to implement the netvsc PMD to service traffic while the VF is revoked and fall back to the synthetic vmbus.

20. How will you ensure feature parity with mlx4/mlx5, which support a broader range of features?

[Brian]: Mellanox creates network cards for a broad customer base that includes all the major public cloud platforms as well as retail.  Microsoft does not sell the MANA NIC to retail customers and does not have to support features that are not relevant to Azure. One of the primary benefits of MANA is we can keep functionality specific to the needs of Azure and iterate quickly.

21. Is it possible to select which NIC is used in the VM (MANA or mlx), and for how long will mlx support be available?

[Brian]: No, you will never see both MANA and Mellanox NICs on the same VM instance. Additionally, when a VM is allocated (started) it will select a node from a pool of hardware configurations available for that VM size. Depending on the VM size, you could get allocated on ConnectX-3, ConnectX-4 Lx, ConnectX-5, or eventually MANA. VMs will need to support mlx4, mlx5, and mana drivers till hardware is retired from the fleet to ensure they are compatible with Accelerated Networking.

22. Will there be support for Windows and FreeBSD with DPDK for MANA?

[Brian]: There are currently no plans to support DPDK on Windows or FreeBSD. However, there is interest within Microsoft to run DPDK on Windows.

23. What applications are running on the SoC?

[Brian]: The SoC is used for hardware offloading of host agents that were formerly ran in software on the host and hypervisor. This ultimately frees up memory and CPU resources from the host that can be utilized for VMs and reduces impact of neighbor noise, jitter, and blackout times for servicing events.  

24. What applications are running on the FPGA?

[Brian]: This is initially restricted to I/O hardware acceleration such as RDMA, the MANA NIC, as well as host-side security features.

Read the full user story ‘Unleashing Network Performance with Microsoft Azure MANA and DPDK’

Author: Kamalakshitha Aligeri – Senior Software Engineer at Arm

The objective of DPDK is to accelerate packet processing by transferring the packets from the NIC  to the application directly, bypassing the kernel. The performance of DPDK relies on various factors such as memory access latency, I/O throughput, CPU performance, etc.

Efficient packet processing relies on ensuring that packets are readily accessible in the hardware  cache. Additionally, since the memory access latency of the cache is small, the packet processing  performance increases if more packets can fit into the hardware cache. Therefore, it is important  to know how the packet buffers are allocated in hardware cache and how it can be utilized to get  the maximum performance. 

With the default buffer size in DPDK, hardware cache is utilized to its full capacity, but it is not  clear if this is being done intentionally. Therefore, this blog helps in understanding how the  buffer size can have an impact on the performance and things to remember when changing the  default buffer size in DPDK in future. 

In this blog, I will describe, 

1. Problem with contiguous buffers 

2. Allocation of buffers with cache awareness 

3. Cache awareness in DPDK mempool 

4. l3fwd performance results with and without cache awareness 

Problem with contiguous buffers 

The mempool in DPDK is created from a large chunk of contiguous memory. The packets from  the network are stored in packet buffers of fixed size (objects in mempool). The problem with  contiguous buffers is when the CPU accesses only a portion of the buffer, such as in cases like  DPDK’s L3 forwarding application where only metadata and packet headers are accessed. Rest of  the buffer is not brought into the cache. This results in inefficient cache utilization. To gain a better  understanding of this problem, its essential to understand how the buffers are allocated in hardware  cache. 

How are buffers mapped in Hardware Cache? 

Consider a 1KB, 4-way set-associative cache with 64 bytes cache line size. The total number of  cache lines would be 1KB/64B = 16. For a 4-way cache, each set will have 4 cache lines. Therefore, there will be a total of 16/4 = 4 sets. 

As shown in Figure1, each memory address is divided into three parts: tag, set and offset. 

• The offset bits specify the position of a byte within a cache line (Since each cache line is  64 bytes, 6 bits are needed to select a byte in a single cache line). 

• The set bits determine which set the cache line belongs to (2 bits are needed to identify the  set among 4 ways).

• The tag bits uniquely identify the memory block. Once the set is identified with set bits,  the tag bits of the 4 ways in that set is compared against the tag bits of the memory address,  to check if the address is already present in the cache. 

Figure 1 Memory Address 

In Figure 2, each square represents a cache line of 64 bytes. Each row represents a set. Since it’s a  4-way cache, each set contains 4 cache lines in it – C0 to C3. 

Figure 2 Hardware Cache 

Let’s consider a memory area that can used to create a pool of buffers. Each buffer is 128 bytes,  hence occupies 2 cache lines. Assuming the first buffer address starts at 0x0, the addresses of the  buffers are as shown below. 

Figure 3 Contiguous buffers in memory

In the above figure the offset bits are highlighted in orange, set bits in green and tag bits in blue. Consider buffer 1’s address, where set bits “00” means the buffer maps to set0. Assuming initially  all the sets are empty, buffer 1 occupies the first cache line of 2 contiguous sets. 

Since buffer 1 address is 0x0 and the cache line size is 64 bytes, the first 64 bytes of the buffer  occupy the cache line in set0. For the next 64 bytes, the address becomes 0x40 (0b01000000) indicating set1 because the set bits are “01”. As a result, the last 64 bytes of the buffer occupy the  cache line in set1. Thus, the buffer is mapped into cache lines (S0, C0) and (S1, C0). 

Figure 4 Hardware cache with buffer 1 

Similarly, buffer 2 will occupy the first cache line of next two sets (S2, C0) and (S3, C0).

Figure 5 Hardware cache with 2 buffers 

The set bits in buffer 3 address “00” show that the buffer 3 maps to set 0 again. Since the first  cache line of set0 and set1 is occupied, buffer 3 occupies second cache line of set 0 and 1 (S0, C1)  and (S1, C1). 

Figure 6 Hardware cache with 3 buffers 

Similarly buffer 4 occupies the second cache-line of sets 2 and 3 and so on. Each buffer is  represented with a different color and a total of 8 buffers can occupy the hardware cache without  any evictions.  

Figure 7 Allocation of buffers in hardware cache 

Although the buffer size is 128 bytes, CPU might not access all the bytes. For example, for 64 bytes packets, only the first 64 bytes of the buffer are consumed by the CPU (i.e. one cache line  worth of data).  

Since the buffers are two cache lines long, and are contiguous, and only the first 64 bytes of each  buffer is accessed, only sets 0 and sets 2 are populated with data. Sets 1 and 3 go unused (unused  sets are shown with pattern in Figure 8).

Figure 8 Unused sets in hardware cache 

When buffer 9 needs to be cached, it maps to set 0 since set bits are “00”. Considering a LRU  replacement policy, the least recently used cache line of 4 ways (buffer 1, 3, 5 or 7) in set0 will be  evicted to accommodate buffer 9 even though set 1 and set 3 are empty. 

This is highly inefficient, as we are not utilizing the cache capacity to the full.  

Solution – Allocation of buffers with Cache awareness 

In the above example, if the ununsed cache sets can be utilized to allocate the subsequent buffers (buffers 9 – 16), we would utilize the cache in a more efficient manner. 

To accomplish this, the memory addresses of the buffers can be manipulated during the creation  of mempool. This can be achieved by inserting one cache line padding after every 8 buffers,  effectively aligning the buffer addresses in a way that utilizes the cache more efficiently. Let’s take the above example of contiguous buffer addresses and then compare it with same buffers  but with cache line padding. 

Figure 9 Without cache lines padding Figure 10 With cache lines padding

From figure 9 and 10, we can see that the buffer 9 address has changed from 0x400 to 0x440. With 0x440 address, the buffer 9 maps to set1. So, there is no need to evict any cache line from set0 and  we are utilizing the unused cache set 1. 

Similarly, buffer 10 maps to set3 instead of set2 and so on. This way buffer 9 to buffer 16, can  occupy the sets1 and 3 that are unused by buffers1 to 8. 

Figure 11 Hardware cache with cache awareness 

This approach effectively distributes the allocation of buffers to better utilize the hardware cache. Since for 64-byte packets, only the first cache line of each buffer contains useful data, we are  effectively utilizing the hardware cache capacity by accommodating useful packet data from 16  buffers instead of 8. This doubles the cache utilization, enhancing the overall performance of the  system. 

Padding of cache lines is necessary primarily when the cache size is exactly divisible by the buffer  size (which means buffer size is a power of 2). In cases where the buffer size does not divide  evenly into the cache size, part of the buffer is left unmapped. This residual portion effectively  introduces an offset like the one achieved through padding. 

Cache Awareness in DPDK Mempool 

In DPDK mempool, each buffer typically has a size of 2368 bytes and consists of several distinct  fields – header, object and trailer. Let’s look at each one of them.

Figure 13 Mempool buffer fields 

Header: This portion of the buffer contains metadata and control information needed by DPDK to  manage buffer efficiently. It includes information such as buffer length, buffer state or type and  helps to iterate on mempool objects. The size of the object header is 64 bytes. Object: This section contains actual payload or data. Within the object section, there are additional  fileds such as mbuf, headroom and packet data. The mbuf of 128 bytes contains metadata such as  message type, offset to start of the packet data and pointer to additional mbuf structures. Then  there is a headroom of 128 bytes. The packet data is 2048 bytes that contains packet headers and  payload. 

Trailer: The object trailer is 0 bytes, but a cookie of 8 bytes is added in debug mode. This cookie acts as a marker to prevent corruptions. 

With a buffer size of 2368 bytes (not a power of 2), the buffers are inherently aligned with cache  awareness without the need for cache line padding. In other words, the buffer size is such that it  optimizes cache utilization without the need for additional padding. 

The buffer size of 2368 bytes does not include the padding added to distribute buffers across  memory channels. 

To prove how the performance can vary with a buffer size that is power of 2, I ran an experiment  with 2048 buffer size and compared it against the default buffer size of mempool in DPDK. In the experiment 8192 buffers are allocated in the mempool and a histogram of cache sets for all  the buffers was plotted. The histogram illustrates the number buffers allocated in each cache set. 

Figure 14 Histogram of buffers – 2048 bytes 

With a buffer size of 2048 bytes, the same sets in the hardware cache are hit repeatedly, whereas  other sets are not utilized (we can see that from the gaps in the histogram) 

Figure 15 Histogram of buffers – 2368 bytes

With a buffer size of 2368 bytes, each set is being accessed only around 400 times. There are no  gaps in the above histogram, indicating that the cache is being utilized efficiently. 

DPDK l3fwd Performance 

The improved cache utilization observed in the histogram, attributed to cache awareness, is further  corroborated by the throughput numbers of the l3fwd application. The application is run on a  system with 64KB 4-way set associative cache. 

Below chart shows the throughput in MPPS for single core l3fwd test with 2048 and 2368 buffer  sizes 

Figure 16 l3fwd throughput comparison

There is a 17% performance increase with the 2368 buffer size. 

Conclusion 

Contiguous buffer allocation in memory with cache awareness enhances performance by  minimizing cache evictions and maximizing hardware cache utilization. In scenarios where the  buffer size is exactly divisible by the cache size (e.g., 2048 bytes), padding cache lines creates a offset in the memory addresses and better distribution of buffers in the cache. This led to a 17%  increase in performance for DPDK l3fwd application. 

However, with buffer sizes not precisely divisible by the cache size, as is the default in DPDK,  padding of cache lines already occurs because of the offset in the buffer addresses, resulting in an improved performance. 

For more information visit the programmers guide

The latest DPDK Long Term Stable (LTS) Release 22.11.05 includes several updates and enhancements across various components of the DPDK framework. Significant changes in this release involve numerous file modifications, which are indicated by a large number of insertions and deletions across the codebase. The release notes document extensive additions, suggesting improvements and new features in the areas of network interface controllers (NICs), cryptographic devices, event devices, and baseband processing.

Notable adjustments were made to the build system, documentation, and driver support for various hardware. Improvements in error handling, memory management, and device operation stability are also reflected in the release notes. The release also addresses various bug fixes and performance enhancements to ensure better stability and efficiency.

Contributors

The update involved 246 files with a total of 3,235 insertions and 2,053 deletions. A big shout out to all the contributors to this release including:

Ajit Khaparde, Akhil Goyal, Akshay Dorwat, Alan Elder, Alex Vesker, Ali Alnubani, Andrew Boyer, Anoob Joseph, Arkadiusz Kusztal, Bing Zhao, Bruce Richardson, Chaoyong He, Chengwen Feng, Ciara Power, Dariusz Sosnowski, David Marchand, Dengdui Huang, Edwin Brossette, Eli Britstein, Emi Aoki, Erez Shitrit, Ferruh Yigit, Fidel Castro, Flore Norceide, Ganapati Kundapura, Gregory Etelson, Hamdan Igbaria, Hanumanth Pothula, Hao Chen, Harman Kalra, Hernan Vargas, Holly Nichols, Huisong Li, Jie Hai, Jonathan Erb, Joyce Kong, Kaiwen Deng, Kalesh AP, Kevin Traynor, Kiran Kumar K, Kishore Padmanabha, Kommula Shiva Shankar, Konstantin Ananyev, Kumara Parameshwaran, Long Li, Luca Boccassi, Maayan Kashani, Masoumeh Farhadi Nia, Maxime Coquelin, Michael Baum, Mingjin Ye, Morten Brørup, Mário Kuka, Neel Patel, Nithin Dabilpuram, Pavan Nikhilesh, Pengfei Sun, Qi Zhang, Qian Hao, Radu Nicolau, Rahul Bhansali, Rakesh Kudurumalla, Robin Jarry, Rongwei Liu, Satheesh Paul, Shai Brandes, Shaowei Sun, Shihong Wang, Shun Hao, Simei Su, Sivaprasad Tummala, Sivaramakrishnan Venkat, Stephen Hemminger, Suanming Mou, Sunil Kumar Kori, Sunyang Wu, Tom Jones, Viacheslav Ovsiienko, Wathsala Vithanage, Weiguo Li, Yajun Wu, and Yunjian Wang.

These contributors addressed various aspects from software fixes and performance enhancements to security improvements across multiple components of the system.

Download it here: DPDK 22.11.5

The git tree for this version can be accessed here: DPDK Stable 22.11

In the rapidly evolving digital landscape, hyperscaling in the cloud has emerged as a critical strategy for businesses aiming to scale their operations efficiently. The webinar, “Hyperscaling in the Cloud,” hosted by Honnappa Nagarahalli (Arm), from the DPDK Tech Board, brings together industry experts to discuss how the Data Plane Development Kit (DPDK) is revolutionizing hyperscale cloud environments.

The Webinar Panelists

The webinar featured three distinguished panelists:

1. Brian Denton: A Senior Program Manager at Microsoft Azure, Brian brings a wealth of experience in Azure’s host networking. He shared insights into Azure’s implementation of DPDK, emphasizing its use in enhancing Ethernet, and overall network performance.

2. Rushil Gupta: As a Senior Software Engineer at Google, Rushil highlighted the critical role of DPDK in financial technology (Fintech) applications on Google Cloud Platform (GCP). His discussion focused on achieving consistency, performance, and reliability in high-frequency trading platforms.

3. Jim Thompson: Co-founder of Netgate, Jim delved into the use of DPDK in networking applications outside the traditional cloud domain. His contribution illuminated the versatility of DPDK across different cloud environments and its impact on virtual private networks (VPNs).

Insights from the Webinar

DPDK in Azure’s Cloud Networking

Brian Denton’s presentation offered a glimpse into how Microsoft Azure leverages DPDK to offload packet processing from the CPU to dedicated hardware. This approach significantly reduces latency and improves throughput, enabling Azure to offer enhanced performance for virtual machines (VMs) and networking services.

Brian shared valuable insights into how DPDK has been instrumental in Azure’s network infrastructure, particularly highlighting its impact on Azure’s host networking and the broader ecosystem of partners and customers. He explained that Azure has integrated DPDK to address the need for high-speed packet processing, which is crucial for a wide range of applications, from basic web services to complex, latency-sensitive tasks like real-time analytics and high-frequency trading.

One of the key points Brian made was about the technical architecture that enables Azure to leverage DPDK’s capabilities. He detailed how DPDK is used in conjunction with Azure’s hardware, such as SmartNICs, to offload and accelerate network functions traditionally handled by software. This hardware-software synergy, as Denton explained, not only reduces CPU overhead but also significantly decreases latency, providing Azure customers with improved network performance and efficiency.

Furthermore, Brian highlighted real-world applications of DPDK in Azure, illustrating how partners and customers utilize DPDK for scenarios that require minimal latency and maximum throughput. He also discussed the continuous evolution of Azure’s networking stack, underscored by the introduction of new hardware and the ongoing optimization of DPDK to meet the growing demands of cloud computing.

Some examples: 

Clearent by Xplor used Azure SQL Database Hyperscale to revamp its merchant transaction reporting system. Previously operating on in-house systems, Clearent, which handles over 500 million transactions annually, shifted to a cloud-based setup. This move significantly boosted their ability to process and report data.

Protocall Services, a provider of telephonic crisis and behavioral health digital tools, embarked on a cloud migration journey to enhance the reliability, security, and scalability of its IT infrastructure. 

DPDK’s Impact on Fintech Applications

Rushil Gupta’s discussion on the use of DPDK in financial technology (Fintech) applications, particularly in the realm of high-frequency trading (HFT) platforms on Google Cloud Platform (GCP), sheds light on how bleeding-edge network processing technologies are evolving financial markets. 

In the fast-paced world of HFT, where milliseconds can equate to millions of dollars, the need for ultra-low latency and high throughput is paramount. Traditional cloud networking approaches may falter under such demanding requirements due to the involvement of kernel-based networking stacks that introduce additional latency. Here, DPDK’s bypass of the kernel networking stack, allowing direct access to network hardware, presents a compelling solution. This direct path significantly reduces latency and increases packet processing speed, enabling HFT platforms to operate at the speed required to capitalize on fleeting market opportunities.

Rushil illustrates how Google leverages DPDK to empower fintech customers on GCP, providing them with the infrastructure necessary to achieve the high throughput and low-latency communication essential for HFT platforms. One notable application is in the construction of complex event processing (CEP) systems, which are at the heart of many trading platforms. These systems analyze and act upon market data in real-time, necessitating the rapid processing capabilities that DPDK facilitates.

Rushil discusses the role of DPDK in enhancing data replication and recovery processes within fintech applications. In an industry where data integrity and availability are critical, DPDK’s efficiency in handling large volumes of data packets ensures that financial institutions can maintain robust data replication frameworks. This capability not only supports the high availability demands of trading platforms but also aids in achieving regulatory compliance related to data persistence and recovery.

Rushil explained how DPDK’s application in fintech on GCP demonstrates the technology’s pivotal role in enabling HFT and other financial services to meet their stringent performance and reliability criteria. With DPDK, Google provides a competitive edge to fintech applications, facilitating new levels of speed and efficiency in financial markets. 

Some examples: 

1. CME Group. As one of the world’s leading derivatives marketplaces, CME Group leverages GCP and DPDK for enhanced market data analytics and to facilitate high-speed trading. Their partnership aims to accelerate CME Group’s move to the cloud, transforming the global markets ecosystem with cloud-based innovation and scaling capacity dynamically to meet market demands.

2. Talos. Specializing in digital asset trading technology, Talos utilizes GCP’s infrastructure to support its trading platform. With DPDK, Talos benefits from reduced latency and increased throughput, essential for executing trades and managing orders across multiple exchanges and liquidity pools efficiently.

3. Clowd9. This cloud-based trading technology provider uses GCP to offer a scalable and secure platform for trading firms and financial institutions. DPDK supports Clowd9’s need for high performance and low latency in executing trades, managing risk, and processing real-time market data.

4. Freetrade. Freetrade, an investment platform, leverages GCP to power its app, offering users commission-free trading. GCP’s global infrastructure and DPDK’s network optimization capabilities ensure that Freetrade can manage high volumes of transactions and data analysis. 

5. TD Securities Automated Trading (TDSAT): TDSAT uses GCP for trading fixed-income bonds, benefiting from DPDK’s high-performance packet processing capabilities. This enables TDSAT to execute trades at high speed and with precision, critical for maintaining competitiveness in the fixed income market.

These customers and use cases underscore the importance of DPDK in enhancing network performance on GCP, making it an ideal platform for capital market applications that demand high throughput, low latency, and scalability. By leveraging GCP and DPDK, capital market firms innovate and adapt quickly to market changes, manage risks more effectively, and unlock new opportunities for growth.

Broadening DPDK’s Application Scope in VPNs and Software Routers

Jim Thompson’s insights during the DPDK webinar shed light on how DPDK is leveraged in cloud networking through the lens of Netgate’s product, TNSR (pronounced ‘Tensor’). This serves as a case study of DPDK’s implementation outside its traditional use cases. TNSR, a virtual router developed by Netgate, underscores the adaptability and robustness of DPDK in addressing specific cloud networking challenges.

In cloud environments, networking demands can quickly escalate due to the sheer volume of data transfer and the need for secure connections. Traditional VPN solutions often fall short due to bandwidth limitations and the number of tunnels they can support. Jim highlighted how these constraints could hinder the scalability and performance of cloud-based services. This scenario is particularly relevant for large organizations that require extensive interconnectivity across various cloud environments.

The introduction of TNSR as a DPDK-powered solution exemplifies how DPDK’s high-performance packet processing capabilities can be extended beyond typical use cases to solve complex cloud networking problems. By utilizing DPDK’s efficient polling mode drivers (PMDs) for network and cryptography offload, TNSR significantly enhances throughput and reduces latency in VPN connections. 

Jim explained how TNSR facilitates seamless connectivity between on-premise networks and cloud regions, highlighting the importance of VPN connections for secure data transfer. He underscored the limitations of existing cloud VPN solutions, such as bandwidth caps and tunnel number restrictions, which can significantly hamper large organizations’ networking needs. By leveraging DPDK, TNSR bypasses these limitations, providing a more flexible and scalable solution for cloud-based networking.

Take a look at Netgate’s customer stories here. 

Conclusion

The webinar underscored DPDK’s pivotal role in enabling hyperscaling in the cloud. By providing a high-performance packet processing framework, DPDK not only enhances network efficiency but also opens new avenues for application development across various industries. As cloud architectures continue to evolve, the collaboration between cloud providers, technology firms, and the open source community will be vital in harnessing the full potential of DPDK.

Join in the Hyperscaling discussion and the community on slack here.

The latest DPDK release, version 22.11.4, brings several important updates, bug fixes, and improvements across various components of the DPDK framework. In this blog post, we’ll provide a brief summary of the key changes and highlights in this release.

Release Highlights:

1. Updated Git Tree: You can access the latest DPDK source code on the official Git repository at DPDK Stable Git Tree. 

2. Bug Fixes and Backports: This release includes numerous bug fixes and patches, thanks to the efforts of the community, which contribute to the stability and reliability of the DPDK framework.

3. Security Improvements: The release addresses security-related issues and provides enhancements to improve the overall security of the DPDK.

4. Documentation Updates: The DPDK documentation has been updated, including improvements to guides for various NICs and platforms. The release also includes updates to the Security Guide and VDPA (Virtio Data Path Acceleration) documentation.

5. Performance Enhancements: DPDK is known for its high-performance networking capabilities, and this release continues to optimize and improve performance across different components.

6. Driver Updates: Multiple network drivers have been updated and improved in this release, including fixes for checksum offloading, packet handling, and performance tuning.

7. Eventdev Improvements: The eventdev subsystem has seen enhancements, including fixes related to device pointer management and driver names in the info struct.

8. Crypto Libraries: Various crypto libraries have been updated and fixed, including the addition of missing documentation for security context and memory leak fixes in the OpenSSL PMD.

9. Mempool Fixes: Several fixes have been applied to the mempool component, improving memory allocation and thread safety.

10. Other Component Updates: This release also includes fixes and improvements to other DPDK components, such as the test suite, Ethernet device drivers, and examples.

Overall, DPDK 22.11.4 is a stable release that brings a wide range of improvements, ensuring the continued reliability and performance of the DPDK framework. Users are encouraged to upgrade to this latest release to benefit from the bug fixes and enhancements provided by the DPDK community.

For detailed information about specific changes, you can refer to the official release notes here.

As always, it’s important to thoroughly test any new DPDK release in your specific networking environment to ensure compatibility and performance before deploying it in a production environment.

A Big Shoutout to Our Dedicated Contributors

We want to take this opportunity to express our gratitude to the hardworking individuals who contributed to this release. Their dedication and expertise have made DPDK even more robust and efficient.

Xueming Li, Aakash Sasidharan, Abdullah Sevincer, Akhil Goyal, Alex Vesker, Alexander Kozyrev, Amit Prakash Shukla, Anatoly Burakov, Anoob Joseph, Artemy Kovalyov, Bing Zhao, Brian Dooley, Bruce Richardson, Chaoyong He, Christian Ehrhardt, Ciara Power, David Christensen, David Marchand, Dengdui Huang, Ed Czeck, Eli Britstein, Feifei Wang, Fengjiang Liu, Ferruh Yigit, Gagandeep Singh, Ganapati Kundapura, Gregory Etelson, Harman Kalra, Harry van Haaren, Hemant Agrawal, Hernan Vargas, Huisong Li.

Navigating the Data Plane Development Kit (DPDK) release landscape requires a thorough understanding of what a Long-Term Stable (LTS) release entails and why it may be the preferred choice for certain network environments. This guide dives into the nuances of DPDK LTS, its suitability for production, and the level of active support it receives.

Understanding DPDK Long Term Stable (LTS) Releases

DPDK LTS releases stand out in the networking world for their reliability over an extended period. Here’s what sets them apart:

Longevity of Support: DPDK LTS offers a commitment of three years’ worth of fixes, ensuring that a chosen release remains robust against issues found long after its initial deployment.

Consistent Improvements: A DPDK LTS release isn’t static. It evolves with a series of API/ABI compatible drop-in replacements that incorporate the latest fixes discovered in the subsequent years. For instance, a series based on a 2022 DPDK release will be refined with fixes identified during 2023-2025.

Sustainability: This approach guarantees that production environments can rely on a consistent, stable platform without the need to constantly adapt to new feature changes.

DPDK LTS releases are tailored for specific scenarios within the networking domain

Ideal for Production: LTS releases are the go-to for production environments where stability is paramount and the latest features are less of a priority.

Focus on Stability Over Novelty: Organizations that value long-term reliability over cutting-edge features will find DPDK LTS releases more suitable.

Active Maintenance and Support

The vibrancy of the DPDK LTS ecosystem is reflected in the following statistics:

Multiple Active Releases: As of now, three LTS releases are being actively maintained: 21.11, 22.11, and 23.11.

Frequent Updates: 2023 saw 9 releases across these maintained LTS versions.

Volume of Fixes: Approximately 1800 fixes have been backported to the active DPDK LTS releases in the last year alone.

Maintenance Span for DPDK LTS

The commitment to maintain a DPDK LTS release is clear and long-term:

General Fixes: All identified fixes will be backported to the LTS releases for a full three years from their release date.

Security Patches: Security-related updates may even extend beyond the three-year window, ensuring that LTS releases maintain a strong defense against vulnerabilities.

Choosing a DPDK LTS Release

When deciding on a DPDK LTS release, consider the following:

Maintenance Timeline: Evaluate whether longer support windows aligns with your deployment cycle and update capacity.

Active Maintenance Record: The volume and frequency of backported fixes provide an indication of the LTS version’s vitality and the community’s dedication to its upkeep.

Security Commitment: With a promise of three-plus years of security fixes, assess whether this meets your organization’s security and compliance requirements.

Preparing for DPDK LTS Deployment

Transitioning to or between DPDK LTS releases requires an organization to:

Stay Informed: Keep abreast of the DPDK LTS release and maintenance schedules to time updates strategically.

Test Thoroughly: Allocate resources for detailed testing to ensure the LTS version integrates seamlessly with your environment.

Anticipate Adjustments: Be prepared for any necessary changes that might arise from the introduction of backported fixes.

Conclusion

Selecting a DPDK LTS release is a strategic decision influenced by the need for stability, long-term support, and a maintenance schedule that ensures network applications remain secure and performant. 

With the extended support and backporting of fixes, DPDK LTS releases offer a dependable foundation for organizations seeking a stable networking stack. This maintenance model continues to be a cornerstone of network reliability, allowing organizations to leverage stable and secure networking functions without the churn of constant feature updates.

For more information visit: https://doc.dpdk.org/guides/contributing/stable.html

Authors: Ben Thomas (Linux Foundation Marketing Lead) & Kevin Traynor (LTS Maintainer & Software Engineer @ Redhat)

Navigating the complex landscape of Data Plane Development Kit (DPDK) releases, particularly Long-Term Support (LTS) versions, is often accompanied with pressing questions: “Which release is most suitable for my needs?” “What are the advantages of choosing an LTS release?” “How does an LTS release impact the stability and life span of my network applications?” 

This detailed blog aims to shed light on these queries and steer you towards the appropriate DPDK LTS release for your specific requirements.

Understanding DPDK LTS Releases

DPDK is a collection of libraries and drivers that enable rapid packet processing, which is essential in network functions virtualization (NFV), cloud computing, and other high-speed networking environments. 

LTS releases are special in that they are designated to receive ongoing maintenance updates, including bug fixes and security patches, for a longer duration than standard releases.

DPDK LTS vs. Standard Releases

DPDK standard releases are known for their rapid development and inclusion of bleeding-edge features. In contrast, LTS releases follow a more systematic and stable approach, focusing on a consistent cadence of fixes and releases. 

This distinction is important for organizations deciding between adopting the latest DPDK features or prioritizing long-term stability, who anticipate a solid three-year cycle of maintenance, with security patches often exceeding this period.

Volume of Fixes in Each Release

A notable characteristic of DPDK LTS releases is the substantial number of fixes each version receives. This high volume of fixes is a testament to the active maintenance and commitment to ensuring the reliability and stability of each LTS version. It indicates the ongoing effort to address a wide range of issues, from minor bugs to critical vulnerabilities. 

Simultaneous Maintenance of Multiple Versions

DPDK’s maintenance strategy includes managing three LTS versions simultaneously. This approach ensures that organizations using different versions of DPDK LTS receive the necessary support and updates. It exemplifies the dedication of the DPDK community to cater to a diverse range of users and their varying adoption timelines.

Differences in Fixes Across Versions

The number of fixes in LTS releases varies based on the age and lifecycle of the release. For instance, an older release like 20.11 tends to have fewer fixes as it matures and stabilizes over time. In contrast, a newer release like 22.11, which was released late in 2022, has not yet completed a full year of fixes. This discrepancy in the number of fixes reflects the evolving nature of each release and the continuous effort to enhance stability and performance.

Impact of Release Timelines on Maintenance

The timing of a release plays a critical role in its maintenance cycle. A newer release like 22.11, having been in the market for a shorter duration, might not have accumulated as many fixes as an older release. This variation underscores the importance of understanding the release timelines and their implications on the maintenance and support cycles of DPDK LTS releases.

Enhanced Focus on NIC and Driver Fixes in LTS Releases

One of the key aspects of DPDK LTS releases is their focus on Network Interface Controller (NIC) and driver fixes. Hardware vendors are deeply invested in driver functionality, making them some of the most active contributors to the DPDK LTS ecosystem. Their involvement is crucial, as they provide the expertise and timely updates necessary to keep the drivers—and thus the network—running smoothly. 

Trends in Bug Fixes and Maintenance

An analysis of recent LTS versions, such as version 22.11.3, reveals a trend of decreasing bug fixes. This trend corresponds to the number of bugs found in the main branch, contrasting with previous versions where fixes averaged around 300. The rate of fixes is not fixed; as a release ages, the number of fixes tends to decrease, indicating increased stability over time.

Longevity of LTS Maintenance

The question of why LTS releases are not maintained for extended periods, like 20 years, is addressed by the trend of diminishing fixes over time. As LTS versions become more stable, the need for frequent fixes decreases, justifying the typical LTS support duration.

Future Code Integrations and Impact on LTS

Looking ahead, future code integrations in DPDK may not significantly impact LTS releases. While library fixes might increase, the core stability of LTS releases is expected to be maintained.

The Process Behind DPDK LTS Releases

The philosophy guiding LTS maintenance encapsulates a straightforward principle: “Don’t make it worse.” Key aspects of this philosophy include:

LTS Selection: Annually, one DPDK release is chosen to become an LTS version. Typically this is the November DPDK release. This release ceases to receive new features but is maintained to address critical issues.

Maintenance Workflow: Fixes from subsequent releases are ported back to the LTS release. For instance, if a significant bug is fixed in a March release, that fix is usually also applied to the LTS version.

Vendor Contributions: Updates for drivers specific to various hardware vendors are included in LTS releases, ensuring that common components remain stable across different platforms.

Validation: LTS releases are validated through a mix of CI and vendors dedicating validation resources.

Distribution Adoption: Prominent Linux distributions such as Red Hat, Ubuntu and Debian favor LTS releases due to their longer support window and relative feature stability.

The Role of LTS in Upstream Maintenance

The DPDK upstream maintainers are committed to ensuring that LTS releases receive the necessary fixes without introducing new issues. This careful balance underscores their dedication to the core LTS premise.

Statistical analysis of LTS releases provides insight into several key areas:

Fixes: The quantity and significance of the bug fixes an LTS release receives.

Bug Age: The duration that bugs existed before being fixed, indicating the codebase’s stability.

Code Areas: The sections of code that were most frequently fixed, highlighting areas of potential vulnerability or critical importance.

Why Opt for DPDK LTS?

Opting for a DPDK LTS release over a standard one is akin to choosing a well-established airline for travel—while it may not boast the newest features, its track record for safety is impeccable.

Industry Adoption

Companies like Red Hat and Ubuntu use LTS releases because they trust the extended support period will provide a stable foundation for their network infrastructure. This trust stems from the methodical maintenance and broad community endorsement of LTS releases, which adds another layer of testing and quality assurance.

Community and Self-Support

While LTS releases are backed by community support, there is nothing to prevent organizations from taking on their support initiatives. For example, if a company needs to support a particular network card with custom features, they can take an LTS release and integrate their changes while still benefiting from the core stability that LTS provides.

Update Overhead

LTS offers flexibility of when to update to the next LTS. If a new feature of interest is available in the next LTS then it can be worth the effort to update and also extend the longevity of using a maintained release.

If not, then it is fine to skip and wait for a later LTS. Staying with an LTS series means less effort to get fixes. It also means API/ABI compatibility, so there are no application code changes needed and less frequent product integration testing.

What if there’s a new interesting feature that is not yet in an LTS release yet? With one LTS released per year, there is always another one coming soon.

Example Integration into Other Projects

Open source projects like Open vSwitch (OVS) integrate DPDK LTS to enhance their performance. Each year the OVS project takes the newest DPDK LTS and integrates into their next release. This means that OVS users benefit from fixes and stability in the underlying DPDK drivers that it uses.

Which LTS Release Should You Pick?

The choice of the right DPDK LTS release hinges on various factors:

Support Window: Assess the duration of support your deployment requires.

Feature Set: Determine whether the LTS release contains the necessary features for your network applications, keeping in mind that it takes time for new features to become stable.

Vendor Compatibility: Check if the LTS release supports your hardware and if vendor-specific drivers are maintained.

Preparing for Transition: From LTS to LTS

Transitioning from one LTS release to the next requires careful planning. As exemplified by maintainers like Kevin Traynor in the 21.11 release, the process is detailed but manageable. Organizations should:

• Stay informed about the DPDK stable release schedule and plan their updates accordingly.
• Dedicate time to comprehensive testing when updating versions.
• Anticipate and prepare to address possible integration issues.

The Future of DPDK LTS Releases

Looking forward, DPDK LTS releases will continue to be a cornerstone for networks that value stability. The DPDK community, in conjunction with hardware vendors, is committed to ensuring that LTS releases are equipped to handle the demands of modern networking environments. 

As we navigate this terrain, the feedback loop between users and maintainers will remain vital. Each fix, each update, and each LTS release is a product of collective effort and shared knowledge.

Call to Action: Join the Effort

As the DPDK LTS ecosystem thrives, we extend an open invitation to more companies and contributors to provide their input and expertise. Whether you’re a hardware vendor with an eye on driver optimizations or an enterprise leveraging DPDK for high-performance networking, your experiences and contributions are invaluable. The strength of an LTS release is not just in its code—it’s in the community that molds and shapes it.

Learn more about DPDK LTS releases here

Introduction:
The latest DPDK version 23.11, is now available. This version includes latest updates and new features in network processing.

Download Link: https://fast.dpdk.org/rel/dpdk-23.11.tar.xz

Release Statistics:

Commits: This release comprises 1161 commits from 161 authors.

File Changes: There were modifications to 1647 files, which include 97,078 insertions and 44,688 deletions.

Support Duration:
The 23.11 version will be supported for three years, indicating its reliability for system integration and deployment.

ABI Versioning: New Major ABI Version: This release introduces major ABI version 24.

Future Releases: The forthcoming 24.03 and 24.07 versions will maintain compatibility with ABI version 23.11.

Main Features of the Release:

• C11 Compiler Requirement: The build now mandates a C11 compatible compiler.
• MSVC Build Support: Initial support is added for Microsoft Visual C++ (MSVC) builds.
• New Atomic Operations API: An enhanced API for atomic operations is included.
• AMD CPU Power Management: Advanced power management features for AMD CPUs.
• MBuf Recycling: Enhancements in memory buffer recycling.
• RSS Algorithm Management: Upgraded management of Receive Side Scaling (RSS) algorithms.
• Max Rx Buffer Size Adjustment: Modifications to the maximum receive buffer size.
• New Flow Action Types: Introduction of novel flow action types.
• Flow Group Miss Action: A new flow group miss action feature is added.
• Packet Type Matching: Improved packet type matching in flow items.
• TLS Record Offload: New offloading capability for TLS record processing.
• Security Rx Inject: Advanced features for security reception injection.
• Eventdev

Enhancements:

• Updates in eventdev link profiles, adapter for dmadev, and the event dispatcher library.
• NFP vDPA Driver: A new driver is introduced.
• Graph Application: A novel application feature for graph processing.
• Deprecated Libraries: Certain libraries and drivers have been removed.

Detailed Release Notes: https://doc.dpdk.org/guides/rel_notes/release_23_11.html

Contributor Acknowledgments:
The release includes contributions from 40 new individuals across various roles like authors, reviewers, and testers.

A big shoutout to Alan Brady, Ales Musil, Andrey Ignatov, Artemy Kovalyov, Chang Miao, Fengjiang Liu, Igor de Paula, Jayaprakash Shanmugam, John Romein, Jonathan Erb, Jonathan Tsai, Josh Hay, Julian Grajkowski, Karen Kelly, Kuan Xu, Madhu Chittim, Mahesh Adulla, Matthew Dirba, Paul Szczepanek, Peter Nilsson, Sam Andrew, Sampath Peechu, Saurabh Singhal, Shailendra Bhatnagar, Shihong Wang, Shubham Rohila, Shujing Dong, Sibaranjan Pattnayak, Sinan Kaya, Sivaprasad Tummala, Sivaramakrishnan Venkat, Timothy Miskell, Tomer Shmilovich, Trevor Tao, Trevor Tao, Vamsi Krishna Attunuru, Wajeeh Atrash, Wei Hu, Xiaoming Jiang, Zhenning Xiao.

The DPDK Summit 2023 was a showcase of technical breakthroughs and forward-looking discussions in the field of high-performance networking. The summit featured a range of presentations, each diving into new developments and future directions. Here are the highlights from the key talks.

Keynote Session: Welcome & Opening Remarks – Rashid Khan, Senior Director, Software Engineering RHEL Networking, Red Hat

Rashid commenced with a nod to the global audience, addressing the challenges and breakthroughs in DPDK’s trajectory. He extended his gratitude toward the contributions made by the DPDK Board of Governors, the project’s contributors, and the sponsors who fuel the initiative’s progress.

Augmenting P4 Software Pipelines with Accelerators. The IPsec Use-case – Cristian Dumitrescu & Radu Nicolau, Intel Corporation

Intel’s Cristian Dumitrescu and Radu Nicolau presented a method to boost P4 software pipelines using standalone software modules called extern blocks. Focusing on IPsec, they demonstrated how to employ DPDK libraries to add acceleration to P4 pipelines, enabling them to handle IPsec processing in parallel with regular pipeline functions. The IPsec block, working as an accelerator, is seamlessly integrated using packet queues and supports multiple security protocols without needing changes to the P4 pipeline code.

Leveraging DPDK for P4 SmartNIC Applications – ESnet

Sean Cummings and Chris Cummings from ESnet discussed the use of DPDK as an offload engine for P4 SmartNIC applications. They highlighted how DPDK can manage complex packet translations that P4 cannot, using their experience with a SIIT-DC NAT64 translator on FPGAs as a case study.

OVS and Offloading Frameworks Comparison – Red Hat

David Marchand from Red Hat analyzed tc-flower and rte_flow, two frameworks used for offloading complex packet processing to NICs within OVS. He provided insights into the performance and integration status of rte_flow compared to tc-flower.

rte_flow Offload to Virtio – Red Hat

Christophe Fontaine from Red Hat presented the application of rte_flow to virtual interfaces, explaining the benefits and the performance gains achievable, which elevate virtio’s capabilities from 4Mpps to line-rate.

VDUSE Performance Check – Red Hat

Maxime Coquelin from Red Hat compared the performance of VDUSE with other solutions like Vhost-user and VETH pairs in conjunction with Virtio-vDPA, building upon the previous year’s introduction to VDUSE’s architecture.

Cloud Native DPDK vCSR for 5G – Juniper Networks

Kiran KN and Shailender Sharma from Juniper Networks introduced a cloud-native virtual DPDK Cell Site Router (vCSR) designed for the 5G ORAN ecosystem. They detailed its architecture, integration with Juniper’s control plane, and its role in enhancing connectivity in a disaggregated RAN setup.

5G RAN and UPF Acceleration – NVIDIA

Elena Agostini and Gal Cohen from NVIDIA spoke about accelerating 5G RAN and UPF. Elena focused on the NVIDIA Aerial SDK’s use of DPDK for building a 5G software stack, while Gal discussed the benefits of using SmartNICs and DPUs for UPF, highlighting the scalability and performance enhancements provided by DPDK.

ABI Versioning in DPDK – AMD

Ferruh Yigit from AMD provided a thorough explanation of ABI versioning in DPDK. He discussed the application of ABI versioning, a topic that has seen limited use and understanding, offering a step-by-step guide and examples for its implementation in DPDK.

Advancing CI Pipelines: Insights by Aaron Conole of Red Hat, Inc.

Aaron Conole’s session revolved around the evolution of CI pipelines within the DPDK ecosystem. He took the audience through a brief history of CI infrastructure development and outlined the current landscape. The crux of his talk was the envisioned transformation of the CI pipeline into a decisive factor for patch acceptance. 

Using Sharable Mempools for Zero-copy Sharing Between Processes – Bruce Richardson, Intel 

This talk addresses the challenges in high-performance packet processing when multiple DPDK processes need to work cooperatively. Normally, splitting a workload across independent processes involves standard inter-process communication (IPC) methods that can be inefficient, as they usually require multiple data copies and complex descriptor manipulations. 

DPDK and Confidential Computing: A Dive by Zhifei Yang from TikTok

Zhifei Yang presented an intriguing session on integrating DPDK with Confidential Virtual Machines, a critical aspect of cloud security. He emphasized how cutting-edge technologies like AMD SEV, Intel TDX, and ARM CCA are empowering users to deploy services in the cloud without fully trusting the cloud provider. Yang pinpointed the unique challenges of running high-performance DPDK applications within CVMs, from the need for shared hugepages to the current suboptimal state of DPDK’s memory management in such environments.

Introducing Advanced IOMMU and VFIO in DPDK

Chenbo Xia and Yahui Cao from Intel led the conversation with an introduction to the integration of new VFIO and IOMMU frameworks within DPDK. The implementation of IOMMUFD in the Linux Kernel calls for DPDK’s alignment to utilize features like PASID/SSID and DMA Page Fault handling. The new VFIO Chardev framework also opens doors to more efficient VFIO device management, promising to refine DPDK’s hardware interactions.

Integrating Arm64 SVE with DPDK

Ruifeng Wang of Arm China talked about the integration of the Arm64 Scalable Vector Extension (SVE) into the DPDK libraries. This integration promises to enhance computational efficiency for network tasks on Arm architectures, leveraging the SIMD feature.

Challenges in DPDK-Based Application Development

Vivek Gupta from Benison Technologies shared insights into the complexities encountered in the development of various DPDK-based applications. He stressed the need for standard solutions that could ease the process of developing and migrating applications to DPDK.

Rust Meets DPDK: Aiming for Security and Performance

Harry van Haaren from Intel suggested leveraging Rust for DPDK functionalities to combine performance with safety. The use of Rust aims to prevent API misuse and provide an easier configuration experience.

Enhancing DPDK RAS through Application Engagement

Ajit Khaparde of Broadcom discussed improving the RAS features in DPDK by involving applications in the error recovery process. Such involvement is crucial for ensuring systems remain robust and reliable.

Bytebricks: A Leap Forward in VPN Frameworks

William Lam from TikTok introduced Bytebricks, a graph library-powered VPN framework that leverages DPDK for superior performance. The framework shows how to manage timers in a scalable way across multiple cores, with a focus on the implementation of the Wireguard protocol.

Sketch-Based Algorithms for Efficient Network Telemetry

Intel’s Leyi Rong talked about sketch-based algorithms in DPDK for network telemetry, which are essential for detecting large network flows while being memory-efficient and computationally effective.

DPDK Graph Library: An In-Depth Look

Jerin Jacob from Marvell provided a detailed overview of the DPDK graph library’s design and implementation, a feature that has enhanced DPDK’s data processing capabilities since its release.

Addressing Performance Issues in DPDK Distribution

Sivaprasad Tummala from AMD addressed the performance challenges faced with DPDK’s distribution packaging, which must cater to various CPU architectures, often at the cost of optimal performance.

dperf: Revolutionizing Network Load Testing

Lastly, Jianzhang Peng from Timeresearch showcased dperf, a network load tester based on DPDK that significantly outperforms traditional testing methods in performance, convenience, and cost.

DTS Working Group Update – Honnappa Nagarahalli, Arm; Juraj Linkes, Pantheon Technologies & Patrick Robb, UNH IOL Lab

The DTS Working Group update was an opportunity to understand the work that had been accomplished, the challenges that had been faced, and what lay ahead. Honnappa Nagarahalli, Juraj Linkes, and Patrick Robb discussed the tangible outcomes of their collaborations, the intricacies of their current projects, and provided a roadmap for future releases. Their talk delved into technical details and discussed how the group’s work aligned with the broader goals of DPDK.

DPI-enhanced DPDK for 5G User Plane – Tobias Roeder, ipoque, a Rohde & Schwarz company

Tobias Roeder’s presentation on DPI-enhanced DPDK threw a spotlight on the intersection of DPDK and 5G technologies. He delved into how deep packet inspection (DPI) could augment DPDK’s capabilities, particularly for the user plane in 5G networks. He talked about the successful application cases, performance benchmarks, and how the integration of DPI with DPDK features like rte_flow and RSS was contributing to the 5G revolution. His presentation rounded out with practical insights from deployments and simulations that mirrored current 5G user behaviors, providing attendees with a grounded perspective on the technology’s current and future impacts.

Closing Remarks – Thomas Monjalon, DPDK Maintainer, NVIDIA

As the summit came to a close, it was essential to reflect on the wealth of knowledge and innovations that had been shared. Thomas Monjalon, a seasoned DPDK maintainer from NVIDIA, concluded the event with his remarks. He recapped the summit’s highlights, underscored the importance of the community’s contributions, and charted the course for the future development of DPDK. He focused on the collaborative spirit that has been a hallmark of DPDK’s success and acknowledged the emerging trends and technologies that would shape its evolution.

Introduction

The open-source community thrives on collective efforts to improve and augment software products. In this post, we take a closer look at the operations of the Data Plane Development Kit (DPDK) community lab and its contributions towards testing and refining the DPDK software project.

DPDK, a set of libraries and drivers for fast packet processing, is embraced by major technology players including Red Hat, NVIDIA, Intel, Arm, and more. However, a crucial element that bolsters the confidence of these companies in DPDK is the dedicated testing Community Lab hosted by the University of New Hampshire Interoperability Lab. Their primary service to the DPDK community involves rigorous testing of code contributions and providing valuable feedback to the developers.

The DPDK Community Lab: An Overview

Initiated around 2017-2018, the DPDK Community Lab was conceived to ensure that incoming code contributions didn’t introduce performance regressions across various vendor channels. Initial testing focused primarily on performance testing and gradually expanded to encompass a broader range of checks.

The lab executes multiple categories of tests on incoming source code contributions, including performance, functional testing, unit and compile testing, and Application Binary Interface (ABI) stability checks. ABI testing provides stability for development across different versions within that cycle. For instance, releases 22.11, 23.03, and 23.07 are/will be ABI compliant with the current major abi version. A new major ABI version will be released with the 23.11 LTS release which may break ABI compliance with releases from the current cycle. But then the subsequent 24.03 and 24.07 releases will be ABI compliant to the ABI major version introduced at 23.11.

The Testing Suite: A Developer’s First Encounter

One of the first steps for developers contributing to DPDK involves navigating the project’s mailing list, where they submit patches for review. Any code change or patch is subsequently passed through the community lab’s testing suite. Should a patch trigger an issue or fail the automated tests, the developers are notified through email as well as the ‘patchwork’ system, an automated web portal that tracks incoming source code patches.

Understanding the testing suite is an essential part of a new developer’s journey. Once developers familiarize themselves with the codebase, the next stage involves learning how to submit patches and navigate the unique mailing list patch archive approach, which can initially be somewhat alien to developers more accustomed to using the major code collaboration and version control tools like GitLab, GitHub, or Bitbucket’s direct patch submission process.

Extending Test Coverage: Evolution Over Time

Over the years, the DPDK community lab has significantly extended its test coverage, adding new types of hardware, architectures, and operating systems to its testing suite. In 2022 and 2023 the Community Lab has worked to update our internal container build system to make it OCI compliant. That has allowed the lab to seamlessly offer the same test coverage for arm64 platforms which was previously offered only for x86 systems. The lab has also made other expansions for ARM, like adding arm32 unit tests to CI runs, and is proud to say there is now parity between x86 and ARM test coverage in the Community Lab.

The lab operates on the principle of relative comparison; it does not publish absolute performance numbers. Instead, it compares the performance of a patch against the mainline version of the codebase. This approach ensures that no individual patch introduces significant performance degradation, which could negatively impact end users and integrators.

Policies and Test Cases

The lab derives its test cases from several sources, primarily the DPDK core developer community and the DPDK Test Suite (DTS). The latter focuses on functional testing and performance testing of the DPDK system as a whole, while the former is focused on individual building blocks within the codebase. There’s an ongoing effort within the community to merge DTS into the DPDK main repository to align its release cycles more closely with those of DPDK itself.

The third category of tests comes from purpose-built sample applications, such as the Federal Information Processing Standards (FIPS) test cases. These cases test the implementation of cryptographic algorithms built into DPDK. With recent advancements from NIST, the lab has transitioned from a manual vector request and testing approach to an automated API-driven process, which greatly facilitates the automation of cryptographic implementation testing.

Testing Methods

At the heart of the lab’s testing approach are three key methods: unit testing, functional testing, and performance testing. Each of these contributes a different perspective, ensuring a comprehensive review of the application. For instance, unit testing focuses on the smallest parts of the application, while functional and performance testing assess the application’s functionality and speed under various conditions.

Compiling is an important step in the process, which they undertake before running ABI (Application Binary Interface) tests. Ensuring that the interface remains consistent is vital, as it confirms the binary formatting of the interfaces isn’t altered. This ensures that applications depending on the DPDK stack don’t face unexpected failures.

The lab’s Continuous Integration (CI) platform, Jenkins, is instrumental in organizing the testing workflow. A graphical representation of our Jenkins Testing Tree can offer a clearer understanding of the testing process, starting from patch application, branching into various forms of testing, and then cycling back for reiteration.

As patches flow into the system, Jenkins starts the process by applying these patches to the DPDK Mainline. If the patches apply correctly, the updated DPDK enters the testing pipeline. The system then breaks down into functional and performance testing using the DPDK Test Suite (DTS) across different servers and network interface cards (NICs). Concurrently, ABI testing ensures consistency at the driver kernel level. Simultaneously, they conduct compile testing on both x86 and ARM architectures. Finally, DPDK’s inbuilt unit tests confirm the robustness of each small part of the software.

Expanding Partner Coverage

In terms of expanding the lab’s test coverage and partnering with member companies, they have historically relied on organic growth within the community. However, recent efforts have focused on DPDK Gold members, targeting the integration of their latest generation hardware into the Lab’s testing suite. This direct engagement ensures their systems are among the first tested by DPDK’s community infrastructure, providing a clear benefit for their participation.

The DPDK Community lab does not eliminate the need for in-house testing, instead it complements it, providing an additional layer of assurance and reliability. Being an open-source project, the lab’s testing capabilities offer wide-ranging coverage, ensuring that the project is robust and dependable. The ongoing expansion of the lab test coverage is testament to the DPDK community’s commitment to delivering consistently robust code. 

Learn more about the DPDK Community Lab testing and for how to get involved visit: https://lab.dpdk.org/results/dashboard/about/