[RFC PATCH] add rust binding support to DPDK

[Van Haaren, Harry]

>From: Owen Hilyard
>Sent: Sunday, April 13, 2025 6:09 PM
>To: Etelson, Gregory; Van Haaren, Harry
>Cc: Richardson, Bruce; dev at dpdk.org
>Subject: Re: [RFC PATCH] add rust binding support to DPDK
>
>Hello all, 
>
>I wanted to chime in as someone who uses DPDK from Rust in quite a few projects.

Great - thanks - more input from different perspectives is good!

<big snip>

> I think most of the value of Rust can be gotten by making a good Rust API available to consumers of DPDK.

Yes - agree here! Adoption of DPDK in Rust ecosystem must "feel normal" just like depending on any other Rust crate.


> There is value in having Rust for PMDs, but there is a lot more code written which consumes DPDK than code in new PMDs. It might be better to hold that conversation until someone wants to write a Rust PMD.

Building PMDs in Rust (while interesting) is not the primary goal here; correct. "End user" of DPDK having a safe and high-performance Rust API is the goal.

> I think that there is also value in a version which is "maximum safety" that takes performance hits where necessary. DPDK is far enough ahead of the performance of most other options that "DPDK at 80%" is still going to be fast enough for many purposes and the extra safety is valuable there from an ease-of-use perspective. There are, of course, applications which need everything DPDK has to offer from a performance perspective, and those should be served as well, but I think DPDK can offer a spectrum where users get steadily closer to "zero overhead abstraction over the DPDK C API" the more performance they need, possibly sacrificing some safety along the way. 

I like this perspective - as hardware vendors its easy to get hyper focused on maximum performance. To be clear; I want to ensure DPDK+Rust can hit max
performance too, but lets focus on Safety/Ergonomics first and then optimize, not the other way around.

I see (Gregory) you posted some more "Rust like abstraction" code for DPDK: https://mails.dpdk.org/archives/dev/2025-April/317088.html
I'll reply there shortly, and give some thoughts on the details as next steps towards a safe/abstracted (but high performance!) API.

Regards, -Harry