Re: [PATCH] rust: RFC/demo of safe API for Dpdk Eal, Eth and Rxq

[Bruce Richardson <bruce.richardson@intel.com>]

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