Upcoming Webinar: Hyperscaling in the Cloud
Skip to main content
All Posts By

benthomas

DPDK Dispatch April

By Monthly Newsletter

1. Main Announcements

2. Blogs, User Stories and Developer Spotlights

3. DPDK & Technologies in the news:

4. Performance Reports & Meeting Minutes

This newsletter is sent out to thousands of DPDK developers, it’s a collaborative effort. If you have a project release, pull request, community event, and/or relevant article you would like to be considered as a highlight for next month, please reply to marketing@dpdk.org

Thank you for your continued support and enthusiasm.

DPDK Team.

First Patch Submission to the DPDK Open-Source Project

By Community Spotlight

Let me first explain why I decided to submit a patch…

Recently, I was working on a research project that utilized the DPDK framework. During the process, I realized that the framework’s driver did not implement all the functionalities specified by the network card. Since one particular functionality, the “launch time feature”, was essential for my work, I spent some time modifying the driver for my project to use this feature.

After that, I decided to invest some time integrating this patch into the DPDK framework, basically for two main reasons. First, I believe this feature is essential for real-time community to use DPDK, and I have seen several discussions online about it, suggesting that its implementation could benefit many others. Secondly, I had never contributed to a large open-source project before and saw this as an opportunity to learn the basic process of submitting patches.

1. Preparation

Before submitting the patch, it’s crucial to understand the project’s development process. DPDK is an open-source project currently managed by Linux Foundation. The development of DPDK happens on the mailing list (like Linux kernel) instead of on GitHub. This means we can’t simply use git commit to submit patches, then followed by a pull request. Instead, patches are submitted via email to maintainers. Therefore, some extra preparatory steps are needed before submission, including:

  • Registering and subscribing to the DPDK mailing list
  • Configuring email to use git-send-email
  • Identifying the maintainers and the subtree of the module you are modifying

Mailing List: The process of registering and subscribing to the mailing list is relatively straightforward and can be done by following the steps in the DPDK official documentation. I won’t repeat that here. I also recommend registering for Patchwork to easily track the code review process. From my experience, it’s best to disable receiving all the emails from the mailing list or set the digest mode to only receive one summary per day, otherwise the daily generated patches will mix with the regular email and overflow the mailbox…

img

Email Configuration: Setting up the email is also quite simple. I used a Google email, and configured it following this article to link git send-email. I didn’t encounter any issues during the process.

Finding Maintainers: DPDK is a large, modular open-source project, designed for collaborative work. Each module has a designated maintainer, and some even have specific maintenance branches. Therefore, it’s necessary to find the maintainer and the branch of the module you want to modify, and submit the patch to them for integration into the mainline repository. An important point to note is to use the script devtools/get-maintainer.sh in the repository to automatically find the maintainers to Cc, just like this:

git send-email –to dev@dpdk.org –cc-cmd devtools/get-maintainer.sh

The first time, I attempted to find maintainer information in the list provided in the documentation and manually added it to the CC field. However, I later discovered that this information was outdated, which led me to inadvertently send the patch to a previous maintainer…

As for understanding the project’s coding style, I suggest not spending too much time studying the official style guide. This is because you can ensure the consistency of the coding style with the automated review scripts mentioned later.

2. Writing the Patch

The process of writing the patch is essentially modifying the original code to fix bug or add new functionalities, and after formatting it with diff, these modifications become the patch. An important suggestion here is to disable the auto-formatting feature of your IDE. Many projects have unique code formatting styles, and auto-formatting might mess up the format with Tab/Space changes everywhere.

2.1 Testing

Testing is divided into three main parts:

  • Compilation and functional testing
  • Code style check
  • ABI Policy

Compilation and Functional Testing: Since my modifications were minor, I only compiled it on my local machine. The specific process is largely similar to installing DPDK, except the first step involves using meson setup –wipe build to clear the previous build directory. For functional testing, I recommend testing all DPDK built-in apps that might be affected, such as dpdk-testpmd.

Code Style Check: This part can be done following the Section 5.7 Checking the Patches in the DPDK official tutorial. It’s important to note that you need to download checkpatch.pl yourself (You can get the source code by Google searching, just a simple script). After generating codespell-dpdk.txt as instructed, run devtools/checkpatches.sh patch_name.patch in the same directory. The output log shows the results, where both errors and warnings need to be corrected, but some checks may not need changes if they are unreasonable.

ABI Policy: ABI Policy refers to the requirements for variable and function naming. It is recommended to self-check against the official ABI Guideline. But personally, I feel if no new file is created, there shouldn’t be many issues, just compare with the surrounding code to get a sense of the appropriate naming conventions.

2.2 Submitting the Patch

After testing, it is good to generate the patch. Before doing so, it’s recommended to double-check your git username and email, using git config –global user.name & git config –global user.email.

My method of generating patches might not be the best practice. I initially used git add & git commit for a simple commit, then git commit –amend to modify the commit message. Finally, I generated the patch with git format-patch -1 -o ~/patch/. Here -1 indicates the patch-set includes the last few commits, but I only needed to generate one patch.

Before submission, check if the patch contains the Signed-off-by: xxxxx <xxxxxx@xxx> line. Mine wasn’t generated automatically, so I added it manually.

Finally, the patch can be submitted via git send-email, typically –to the mailing list dev@dpdk.org, and –cc to maintainers.

git send-email \

–to dev@dpdk.org \

–cc-cmd devtools/get-maintainer.sh \

./patch_name.patch

Before sending, it is best to first send it to yourself to check if the email format is correct with git send-email –to=[your email] patch_name.patch.

If you have registered for Patchwork, you’ll receive the patch submission notification after a few hours.

3. Code Review

Compared to smaller open-source projects, code review in DPDK is quite stringent, involving both automated reviews from the system and manual reviews from maintainers.

The results of the automated review are received via email within a few hours of submission. Fortunately, despite this being my first patch submission, no errors were detected with beginner luck.

img

In the subsequent manual review phase, maintainers pose questions about the content of the patch, which feels similar to the rebuttal phase of a research paper submission process. The main issues raised in my case focused on:

  • Explaining the functionality of different lines of code
  • Justifying the chosen solution
  • Providing test results

Responding directly to these questions is usually sufficient. A few minor details to note:

  1. When replying, use the –in-reply-to parameter to specify which email you are responding to.

git send-email \

–in-reply-to=xxxxxxxx.namprd11.prod.outlook.com \

–to=xxxx@xxx.com \

–cc=xxxx@xxx.com \

–subject=”RE: [PATCH] net/e1000: support launchtime feature” \

./reply.txt

  1. Pay attention to formatting. Indicate references to previous emails by adding >.
  2. In the subject, add RE: before the title of the patch. Remember, no matter how many times you reply, there should only be one RE:, not a chain like RE: RE: RE:

4. Lessons

Although the process seemed somewhat complicated to me initially, the friendly atmosphere made it smoother. From submission to the final review, it took me over ten days, which included three replies and one code update. Along the way, I encountered some technical issues and uncertainties. However, these were resolved with the help of the maintainers and other developers, who provided guidance and support throughout the process.

The biggest takeaway for me from this experience is that contributing to a large open-source project is not as daunting as it might seem. It’s often the intricate rules and the stereotypes about open-source communities that dissuade people from getting involved. However, I found that the community was welcoming, and the process, while detailed, was manageable when you are willing to spend some time on it.

Although contributing to the open-source community is not my focus, attempting to submit a patch was definitely a valuable experience.

You can follow Chuanyu on Medium here

And get started with DPDK here

Overview of the Latest DPDK Release 24.03

By Uncategorized

DPDK’s latest release, 24.03, marks the culmination of months of dedicated work and collaboration. Accessible now for download here, this release showcases the efforts of 154 authors, culminating in 987 commits. The extensive changes include 1,334 files being modified, with 79,260 insertions and 22,824 deletions, highlighting the substantial growth and refinement in the project.

Notably, DPDK 24.03 will not have a separate maintenance branch, and it maintains ABI compatibility with the preceding 23.11 version, ensuring a smooth transition for developers.

New Features and Enhancements

The 24.03 release introduces several significant features and improvements, including:

  • A new argument parsing library to streamline application development.
  • Standardization of dynamic logging for enhanced diagnostics.
  • Introduction of the HiSilicon UACCE bus, expanding hardware support.
  • Enhanced query capabilities for transmission queues.
  • Advanced flow matching capabilities including random and field comparison.
  • NAT64 flow action, offering new network translation options.
  • Flow template table resizing for more efficient resource management.
  • Continued preparations for MSVC build support, indicating a commitment to broader compatibility.
  • An expansion of DTS tests and general cleanups to enhance stability and performance.

For a detailed overview of all updates and improvements, read the release here.

Community Growth and Acknowledgments

This release also celebrates the inclusion of 31 new contributors, ranging from authors to reviewers and testers, showcasing the DPDK community’s continuous growth. Contributions spanned across a diverse group of companies, with significant commits from Marvell, NVIDIA, Intel, and many others, reflecting the wide-ranging industry support for DPDK.

Looking Ahead

The project is now looking towards version, 24.07, expected in July. The community is encouraged to submit new feature proposals in the upcoming weeks, aligning with the project’s roadmap available here.

Additionally, the upcoming webinar Hyperscaling in the cloud offers an excellent opportunity for learning and engagement. Interested participants can register here.

Shout Out

A big thank to all courageous people who reviewed other’s work. Based on Reviewed-by and Acked-by tags, the top non-PMD reviewers are:


         50     Akhil Goyal @Marvel
         44     Ferruh Yigit @AMD
         40     Chengwen Feng @Huawei
         36     Anoob Joseph @Marvel
         32     Morten Brørup @Smartsharesystems
         26     Tyler Retzlaff @Linux_Microsoft
         21     Dariusz Sosnowski @NVIDIA
         18     Ori Kam @NVIDIA
         18     Bruce Richardson @INTEL

Download it here

First Patch Submission to the DPDK Open-Source Project

By Uncategorized

Author: Chuanyu Xue – University of Connecticut

Let me first explain why I decided to submit a patch…

Recently, I was working on a research project that utilized the DPDK framework. During the process, I realized that the framework’s driver did not implement all the functionalities specified by the network card. Since one particular functionality, the “launch time feature”, was essential for my work, I spent some time modifying the driver for my project to use this feature.

After that, I decided to invest some time integrating this patch into the DPDK framework, basically for two main reasons. First, I believe this feature is essential for real-time community to use DPDK, and I have seen several discussions online about it, suggesting that its implementation could benefit many others. Secondly, I had never contributed to a large open-source project before and saw this as an opportunity to learn the basic process of submitting patches.

1. Preparation

Before submitting the patch, it’s crucial to understand the project’s development process. DPDK is an open-source project currently managed by Linux Foundation. The development of DPDK happens on the mailing list (like Linux kernel) instead of on GitHub.

This means we can’t simply use git commit to submit patches, then followed by a pull request. Instead, patches are submitted via email to maintainers. Therefore, some extra preparatory steps are needed before submission, including:

  • Registering and subscribing to the DPDK mailing list
  • Configuring email to use git-send-email
  • Identifying the maintainers and the subtree of the module you are modifying

Mailing List: The process of registering and subscribing to the mailing list is relatively straightforward and can be done by following the steps in the DPDK official documentation. I won’t repeat that here. I also recommend registering for Patchwork to easily track the code review process. From my experience, it’s best to disable receiving all the emails from the mailing list or set the digest mode to only receive one summary per day, otherwise the daily generated patches will mix with the regular email and overflow the mailbox…

img

Email Configuration: Setting up the email is also quite simple. I used a Google email, and configured it following this article to link git send-email. I didn’t encounter any issues during the process.

Finding Maintainers: DPDK is a large, modular open-source project, designed for collaborative work. Each module has a designated maintainer, and some even have specific maintenance branches. Therefore, it’s necessary to find the maintainer and the branch of the module you want to modify, and submit the patch to them for integration into the mainline repository. An important point to note is to use the script devtools/get-maintainer.sh in the repository to automatically find the maintainers to Cc, just like this:xxxxxxxxxxgit send-email –to dev@dpdk.org –cc-cmd devtools/get-maintainer.sh

The first time, I attempted to find maintainer information in the list provided in the documentation and manually added it to the CC field. However, I later discovered that this information was outdated, which led me to inadvertently send the patch to a previous maintainer…

As for understanding the project’s coding style, I suggest not spending too much time studying the official style guide. This is because you can ensure the consistency of the coding style with the automated review scripts mentioned later.

2. Writing the Patch

The process of writing the patch is essentially modifying the original code to fix bug or add new functionalities, and after formatting it with diff, these modifications become the patch. An important suggestion here is to disable the auto-formatting feature of your IDE. Many projects have unique code formatting styles, and auto-formatting might mess up the format with Tab/Space changes everywhere.

2.1 Testing

Testing is divided into three main parts:

  • Compilation and functional testing
  • Code style check
  • ABI Policy

Compilation and Functional Testing: Since my modifications were minor, I only compiled it on my local machine. The specific process is largely similar to installing DPDK, except the first step involves using meson setup --wipe build to clear the previous build directory. For functional testing, I recommend testing all DPDK built-in apps that might be affected, such as dpdk-testpmd.

Code Style Check: This part can be done following the Section 5.7 Checking the Patches in the DPDK official tutorial. It’s important to note that you need to download checkpatch.pl yourself (You can get the source code by Google searching, just a simple script). After generating codespell-dpdk.txt as instructed, run devtools/checkpatches.sh patch_name.patch in the same directory. The output log shows the results, where both errors and warnings need to be corrected, but some checks may not need changes if they are unreasonable.

ABI Policy: ABI Policy refers to the requirements for variable and function naming. It is recommended to self-check against the official ABI Guideline. But personally, I feel if no new file is created, there shouldn’t be many issues, just compare with the surrounding code to get a sense of the appropriate naming conventions.

2.2 Submitting the Patch

After testing, it is good to generate the patch. Before doing so, it’s recommended to double-check your git username and email, using git config --global user.name & git config --global user.email.

My method of generating patches might not be the best practice. I initially used git add & git commit for a simple commit, then git commit --amend to modify the commit message. Finally, I generated the patch with git format-patch -1 -o ~/patch/. Here -1 indicates the patch-set includes the last few commits, but I only needed to generate one patch.

Before submission, check if the patch contains the Signed-off-by: xxxxx <xxxxxx@xxx> line. Mine wasn’t generated automatically, so I added it manually.

Finally, the patch can be submitted via git send-email, typically --to the mailing list dev@dpdk.org, and --cc to maintainers.xxxxxxxxxxgit send-email \–to dev@dpdk.org \–cc-cmd devtools/get-maintainer.sh \ ./patch_name.patch

Before sending, it is best to first send it to yourself to check if the email format is correct with git send-email --to=[your email] patch_name.patch.

If you have registered for Patchwork, you’ll receive the patch submission notification after a few hours.

3. Code Review

Compared to smaller open-source projects, code review in DPDK is quite stringent, involving both automated reviews from the system and manual reviews from maintainers.

The results of the automated review are received via email within a few hours of submission. Fortunately, despite this being my first patch submission, no errors were detected with beginner luck.

img

In the subsequent manual review phase, maintainers pose questions about the content of the patch, which feels similar to the rebuttal phase of a research paper submission process. The main issues raised in my case focused on:

  • Explaining the functionality of different lines of code
  • Justifying the chosen solution
  • Providing test results

Responding directly to these questions is usually sufficient. A few minor details to note:

  1. When replying, use the --in-reply-to parameter to specify which email you are responding to.

xxxxxxxxxxgit send-email \ –in-reply-to=xxxxxxxx.namprd11.prod.outlook.com \ –to=xxxx@xxx.com \ –cc=xxxx@xxx.com \ –subject=”RE: [PATCH] net/e1000: support launchtime feature” \./reply.txt

  1. Pay attention to formatting. Indicate references to previous emails by adding >.
  2. In the subject, add RE: before the title of the patch. Remember, no matter how many times you reply, there should only be one RE:, not a chain like RE: RE: RE:

4. Lessons

Although the process seemed somewhat complicated to me initially, the friendly atmosphere made it smoother. From submission to the final review, it took me over ten days, which included three replies and one code update. Along the way, I encountered some technical issues and uncertainties. However, these were resolved with the help of the maintainers and other developers, who provided guidance and support throughout the process.

The biggest takeaway for me from this experience is that contributing to a large open-source project is not as daunting as it might seem. It’s often the intricate rules and the stereotypes about open-source communities that dissuade people from getting involved. However, I found that the community was welcoming, and the process, while detailed, was manageable when you are willing to spend some time on it.

Although contributing to the open-source community is not my focus, attempting to submit a patch was definitely a valuable experience.

Follow Chuanyu Xue on Medium here

Get started with DPDK here

DPDK Dispatch March

By Monthly Newsletter

1. Main Announcements

2. Blogs, User Stories and Developer Spotlights

Want to show your support for the community? Contribute to the new DPDK Dispatch, a monthly round-up of developments from the global community.

  • Submit a blog here
  • Submit a developer spotlight here

3. DPDK & Technologies in the news:

4. Performance Reports & Meeting Minutes

This newsletter is sent out to thousands of DPDK developers, it’s a collaborative effort. If you have a project release, pull request, community event, and/or relevant article you would like to be considered as a highlight for next month, please reply to marketing@dpdk.org

Thank you for your continued support and contributions.

DPDK Team.

New DPDK Release Candidate 24.03 Ready for Testing

By Uncategorized

1. New Features

1.1. HiSilicon UACCE Bus Support

DPDK now supports the HiSilicon UACCE (Unified/User-space-access-intended Accelerator Framework) bus driver, enabling accelerator devices like compressors, cryptos, DMA, and ethernet devices to be seamlessly integrated and registered within DPDK applications.

1.2. Argument Parsing Library

The addition of the argparse library simplifies the development of user-friendly applications by replacing the usage of getopt(), enhancing usability and flexibility in application design.

1.3. Improved RSS Hash Algorithm Support

Enhancements to the RSS hash algorithm support include the addition of rte_eth_find_rss_algo function, allowing for easier retrieval of RSS hash algorithms by name.

1.4. Flow Matching Items

New flow matching items such as RTE_FLOW_ITEM_TYPE_COMPARE and RTE_FLOW_ITEM_TYPE_RANDOM have been introduced, enabling more granular packet field comparison and random value matching in flow processing.

1.5. Flow Template Table Resizing

The ability to resize flow template tables dynamically has been added, providing greater flexibility in managing flow capacities and configurations.

1.6. Updated Drivers

Several DPDK drivers have been updated to include support for new devices and optimize performance. For example, the Marvell cnxk net driver now supports additional flow items like RTE_FLOW_ITEM_TYPE_PPPOES and RTE_FLOW_ACTION_TYPE_SAMPLE, enhancing its capabilities.

2. Removed Items

Certain items, like statically defined logtypes, have been removed from DPDK, emphasizing the shift towards dynamic logtype registration and improved code organization.

3. API Changes

Several API changes have been implemented to align with intended design and improve code robustness, including the removal of typeof(type) from RTE_DEFINE_PER_LCORE macros and the use of C11 static_assert in RTE_BUILD_BUG_ON.

4. ABI Changes

No ABI changes have been made in this release that would break compatibility with the previous version, ensuring seamless migration and backward compatibility.

In summary, DPDK Release 24.03 delivers a significant boost to network acceleration and development efficiency, making it a crucial update for developers and network engineers alike.

🌐 Sources

  1. DPDK Release 24.03 – Documentation

DPDK Dev Spotlight: Sean Cummings Makes his Mark in the DPDK Ecosystem

By Community Spotlight

In the dynamic world of software development, where innovation and skill merge to push the boundaries of technology, Sean Cummings stands as a bright example as a new contributor to DPDK. Currently working as a Student Assistant in Scientific Networking at ESnet, Sean is carving his path in the field of high-performance networking, a journey that started at Illinois Tech under the mentorship of Professor Sultana.

Early Beginnings

Sean’s foray into software development began with his academic pursuits in computer science, where he quickly found himself immersed in the complex world of computer networking. His academic endeavors led him to work on a groundbreaking 100Gbps SIIT-DC stateless NAT64 translator project utilizing P4 on FPGAs.

DPDK: A Game-Changer

The project revealed the limitations of P4 in handling complex packets, which steered Sean towards DPDK. Embracing DPDK as an offload solution, Sean quickly recognized its potential as a vital tool in his development work. His experience with DPDK has been transformative, making him an advocate for its use in high-performance networking.

Contributing to the DPDK Community

Sean’s involvement with DPDK is not just as a user but as an active contributor. He underscores the importance of contributing to communities like DPDK, as it fosters growth and innovation. Sean is particularly excited about the potential applications of DPDK in developing security-related applications.

Getting Involved

For those interested in DPDK, Sean recommends starting with installing it and experimenting with sample applications. This hands-on approach allows one to appreciate the capabilities of DPDK and potentially lead to more complex, personalized projects.

Problem Solving

One of the most impactful pieces of advice that has shaped Sean’s journey is the emphasis on understanding the problem before embarking on the coding journey. This approach underlines the fact that the essence of programming lies in problem-solving, a philosophy that has steered Sean through his developmental endeavors.

Indispensable Tools

As a programmer and researcher, Sean emphasizes the importance of tools like vim (one of the most popular text editors among Linux users) in his daily work. For him, vim is not just a tool but an integral part of his coding and research process.

Conclusion 

Sean represents the new generation of developers who are not just proficient in their craft but are also deeply involved in contributing to and growing with their communities. His journey with DPDK is a testament to his dedication and passion for high-performance networking.

Looking to get started with DPDK? Visit the quick start guide here

Marvell, DPDK and the Rise of Octeon: The Journey to a Systematic Ecosystem

By User Stories

In the rapidly evolving landscape of silicon and networking technologies, providing robust and standardized support for hardware has become a paramount aspect of success. Marvell, a leading provider of silicon solutions, embarked on a transformative journey to ensure seamless support for their Octeon system-on-chip (SoC) through the adoption of DPDK (Data Plane Development Kit). 

This open source framework has emerged as the primary vehicle for Marvell’s silicon support, enabling the integration of sophisticated high-bandwidth accelerators with various applications. This user story dives deep into Marvell’s experiences, showcasing their transition from a chaotic ecosystem to standardized silicon support, and the significant role DPDK played in this evolution.

For this user story we interviewed Prasun Kapoor (AVP of Software Engineering), an accomplished professional with a wealth of experience in software engineering and semiconductor technologies. With a strong background in leading-edge technologies, Prasun has played a pivotal role in shaping the landscape of silicon solutions and networking technologies. As a seasoned AVP of Software Engineering at Marvell, Prasun has demonstrated exceptional leadership and expertise in driving innovation and fostering collaboration within the industry. 

Chaos to Standardization: Overcoming Legacy Code Bases

When Marvell (at the time Cavium) launched its first packet acceleration and security focused multi-core SoC, there was no DPDK. Marvell implemented its own proprietary HAL library, which provided a programming interface very close to the hardware to the end users. 

Many customers implemented large applications built on top of this HAL library and many times forked and customized it to suit their purposes. 

However, transitioning between different silicon generations often disrupted customer applications due to minor changes in the hardware’s programming interface. This challenge was exacerbated by Cavium’s reluctance to make source code for this HAL layer available publicly or contribute it to any open-source project. This prevented Cavium from adopting DPDK from the very beginning.  

The turning point for them came about in 2012-13 when they decided to create a server product. This step forced them to realize the importance of conforming to standard specifications for both hardware and software. It quickly became clear that they would not attract customers without supporting the broader software ecosystem. The previous strategy of relying solely on homegrown solutions was no longer sustainable.

Recognizing the need for a standardized library, Marvell turned to DPDK, an open and collaborative specification for networking and packet processing. By adopting DPDK at the project’s inception, Marvell aimed to provide its customers with a stable and predictable programming interface, eliminating compatibility issues when transitioning between silicon generations. The decision to align with DPDK was a fundamental shift for Marvell, enabling them to provide seamless support for their silicon.

Embracing DPDK and Collaborative Contributions

This shift to open source wasn’t merely a preference but a hard requirement, particularly in the 5G domain. Vendors in the wireless space required every piece of software provided to them to be upstreamable and upstream. This shift indicated a significant decrease in tolerance for proprietary APIs. Cavium’s first foray into open source APIs started with the Open Data Plane (ODP) project, but they adopted DPDK shortly thereafter given the much wider adoption of that framework. 

While the journey to open source had its initial recalcitrance, it proved beneficial from a business perspective. Moreover, the transition to the Data Plane Development Kit (DPDK), an open-source set of libraries and drivers for fast packet processing, was monumental. 

This transition saw Marvell going from a somewhat chaotic system of conflicting proprietary systems to a streamlined operation with enhanced inter-system compatibility and fluidity. The transition also had significant implications for Return on Investment 

“Open-source development is not just a trend; it’s a necessary strategy for technological growth and customer satisfaction. By embracing open-source, Marvell could navigate the complexities of the tech market and build a more sustainable business model.”

Prasun Kapoor, Assistant Vice President – Software Engineering at Marvell Semiconductor

Indeed, the push towards open-source has helped Marvell build a more robust relationship with its customers. The company now engages in regular discussions with its customers, ensuring that every piece of software supplied aligns with their needs and is upstreamable. This level of transparency and collaboration has been invaluable in nurturing customer trust and fostering long-term relationships.

Marvell’s adoption of DPDK went beyond conforming to the specifications. They actively participated in the DPDK community, collaborating with other vendors to propose RFCs and extend the specifications. This approach allowed Marvell to integrate their unique accelerators and technologies into the DPDK framework, ensuring that their hardware was well-supported and widely usable. This enabled the end users to have a single application programming interface to program different class of devices such as ASIC, FPGA or SW for a given workload acceleration.

From the inception of the DPDK project, Marvell recognized the openness and receptiveness of the DPDK community to quality contributions. Initially, many of Marvell’s accelerators had no proper representation in the DPDK APIs. 

As a result, Marvell worked diligently to propose RFCs and establish common API infrastructures that catered to the needs of the entire ecosystem. This collaborative effort ensured that all vendors could leverage the benefits of the standardized APIs and maximize their hardware capabilities.

Marvell’s commitment to collaborative contributions, rather than relying on proprietary APIs, helped establish a level playing field within the DPDK community. They actively extended the specifications and submitted their advancements, ensuring a robust and comprehensive framework for all users. Over the years, Marvell’s contributions have resulted in a vast array of accelerators, such as event accelerator, machine learning accelerators, cryptographic accelerators, memory pool managers, and more, being fully utilizable through standard applications.

The Benefits of DPDK Adoption 

Marvell’s wholehearted adoption of DPDK brought numerous benefits to both the company and its customers. Firstly, the transition between different silicon generations became seamless and predictable. Gone were the disruptions and compatibility issues that plagued the legacy code base approach. 

By adhering to the standardized DPDK APIs, Marvell reduced its support burden significantly, as compatibility was ensured through the collaborative efforts of the DPDK community.

Moreover, Marvell’s adoption of DPDK enabled them to tap into the collective work of other partners and vendors within the DPDK community. This collaboration created a win-win situation, where Marvell could leverage the advancements made by others, while their contributions also benefited the community at large. 

DPDK’s standardized library became the common language among Marvell’s customers, ensuring that requests for functionality tweaks adhered to DPDK compliance. This shift in customer mindset and adherence to the standard further enhanced the stability and scalability of Marvell’s solutions.

Furthermore, the adoption of DPDK opened up opportunities for Marvell to provide standard Red Hat support, which was previously challenging with their MIPS-based systems. Customers expressed a desire to run popular Linux distributions like Ubuntu on Marvell’s chips, prompting the company to embrace the open-source ecosystem fully. 

By submitting kernel code and embracing open-source practices, Marvell gained access to comprehensive support from established Linux distributions, further strengthening their position in the market.

The Role of the DPDK Community Lab

Marvell acknowledges the significance of the DPDK community lab in enhancing the robustness of the project. While they don’t explicitly depend on the community lab for testing and validation, its existence contributes to the overall quality of the DPDK project. 

The continuous validation and rigorous testing conducted in the community lab help identify and address bugs, ensuring that DPDK implementations are reliable and stable.

Marvell’s experience with DPDK has been positive in terms of stability and compatibility. The community lab’s rigorous testing and continuous integration and delivery (CI/CD) processes have played a crucial role in achieving this outcome. 

The lab’s comprehensive testing frameworks and collaborative efforts have resulted in a mature and dependable DPDK framework, which Marvell and other contributors benefit from.

Conclusion 

Marvell’s transition to DPDK illustrates the strength of open-source collaboration, standardization, and community engagement in streamlining support for their Octeon system-on-chip. By aligning with DPDK, Marvell overcame hardware compatibility issues, fostering a more versatile ecosystem. 

This open-source commitment resulted in seamless transitions across silicon generations, creating a predictable application programming interface for customers. 

The integration of Marvell’s accelerators into the DPDK community promoted innovation while preserving compatibility. The presence of the DPDK community lab improved the overall robustness of DPDK implementations, benefiting all contributors. 

Marvell’s DPDK experience underscores the transformative power of open-source collaboration and the benefit of standardized libraries, positioning it as a leading provider of seamless silicon solutions in diverse domains such as 5G, enterprise security, and networking.

Check out the latest videos from Marvell at the DPDK 2023 Summit here.

DPDK Dispatch February

By Monthly Newsletter

1. Main Announcements

  • The latest LTS release 22.11.4, brings several important updates, bug fixes, and improvements. Here’s a summary of the key changes and highlights in this release here
  • Navigate LTS releases in the latest guide here

2. Blogs, User Stories and Developer Spotlights

3. DPDK & Technologies in the news:

4. Performance Reports & Meeting Minutes

This newsletter is sent out to thousands of DPDK developers, it’s a collaborative effort. If you have a project release, pull request, community event, and/or relevant article you would like to be considered as a highlight for next month, please reply to marketing@dpdk.org

Thank you for your continued support and contributions.

DPDK Team.

DPDK LTS 22.11.4

By Blog

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.