On Fri, May 02, 2025 at 03:41:33PM +0000, Gregory Etelson wrote: > Hello Bruce & Harry, > > There is an aspect we've not discussed yet. > > DPDK is a framework. It's integrated into a network application. > > From the application perspective what is a ratio between "pure" > application code and DPDK API ? > The exact numbers differ, but it's clear that most of application code > is not about DPDK. > > Another question to consider - what is more complicated > > rewrite entire application from C to Rust or, while having Rust > application, upgrade or even replace DPDK API ? > > DPDK provides a solid framework for both stability and performance. > > In my opinion, binding DPDK as it is today with Rust can significantly > improve application design. >
I would have initially agreed with that assertion. However, "binding DPDK as it is today with Rust" has already been done many times and never got any real traction that I have seen. Just look at the number of crates coming up when you search crates.io for DPDK[1] - and from a quick scan, many of these are not crates using DPDK, but wrappers around DPDK as it is now (or was a couple of years ago!). Given that it's been attempted so many times before, I really don't see the value in doing it "one more time". If we want to offer support for DPDK through rust, we need to offer something different and better. Any rust developer can already use bindgen to wrap DPDK themselves. That's why I'm trying to see how we can offer something that will be longer term maintainable and usable from rust - rather than just exposing the C APIs. For maintainability we don't want to expose anything that's not absolutely necessary, and for usability we don't want to expose anything that may conflict with what is already there is rust, and for both maintainablity and usability we only should expose that which can't already be done in rust itself or in an existing crate. So I'd view (almost) all thread-management, and most of what EAL provides as not to be exposed to Rust, because Rust already has other ways of doing all that. Similarly for the non-device management libs (i.e. those not like ethdev), functionality for rib/fib/packet rordering/etc. are all better handled by separate crates than by wrapping DPDK. Furthermore, I also tend to be skeptical of the longer-term maintenance of anything that is outside the DPDK repo itself. That's why in my initial RFC, I looked to add to the DPDK repo the minimum hooks needed to make the repo itself a rust crate, rather than having a rust crate that pulls in and wraps DPDK. (Again, there are already a handful of those for users to choose from!) Just my 2c., and where I am coming from. /Bruce [1] https://crates.io/search?q=dpdk
