>From: Owen Hilyard >Sent: Sunday, April 13, 2025 6:09 PM >To: Etelson, Gregory; Van Haaren, Harry >Cc: Richardson, Bruce; dev@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
