Hello Harry,
From: Gregory Etelson <getel...@nvidia.com>
Sent: Thursday, March 6, 2025 1:37 PM
To: dev@dpdk.org <dev@dpdk.org>
Cc: getel...@nvidia.com <getel...@nvidia.com>; tho...@monjalon.net <tho...@monjalon.net>;
mkash...@nvidia.com <mkash...@nvidia.com>; Richardson, Bruce <bruce.richard...@intel.com>
Subject: [PATCH] rust: support DPDK API
Cool, I like this subject, great!
The patch converts include files with DPDK API to RUST and binds new
RUST API files info dpdklib package.
The RUST dpdklib files and DPDK libraries build from C sources
allow creation of DPDK application in RUST.
RUST DPDK application must specify the `dpdklib` package as
dependency in Cargo.toml file.
RUST `dpdklib` package is installed into
MESON_INSTALL_DESTDIR_PREFIX/rust directory.
Software requirements:
- clang
- RUST installation
- bindgen-cli crate
RUST dpdklib installation instructions:
1. Configure DPDK with `-Deanble_rust=true`
2. Build and install DPDK. The installation procedure will create
MESON_INSTALL_DESTDIR_PREFIX/rust directory.
3. Update PKG_CONFIG_PATH to point to DPDK installation.
Interesting approach to automate it; are there specific reasons that this
approach was taken,
or did this just seem the easiest/best way to include "Rust support" into
upstream DPDK?
Alternatives could be (*not* suggesting to rework the patch!) a dpdk-sys
crate where the bindgen etc is done externally to DPDK itself. Many existing
approaches (some examples: https://youtu.be/lb6xn2xQ-NQ?t=130) use that method.
I kind of like (this approach) of having the binding generation upstream with
DPDK itself;
it makes the Rust support upstream and keeps it close to DPDK... however it
means that it is "the one" official/DPDK-community-approved library/crate.
My reason for adding the crate directly into upstream DPDK branch was to produce
a single centralized RUST version of DPDK API.
If DPDK API files are converted externally, there is no control over the result.
Internal crate can help smoothing bindgen translation - DPDK files can be
adjusted to reduce manual translation corrections.
The crate content will be automatically updated after DPDK API change.
Also, internal crate will increate overall RUST awareness in DPDK comunity.
There's some nice tidy-ups to cleanup the namespaces possible if this is "the
crate".
Perhaps (sorry, borderline bikeshed-topics..) renames for clarity &
readability, e.g.:
dpdklib::rte_eal::rte_eal_init()
The crate exports existing DPDK API to RUST application as it is.
This way RUST application receives stable DPDK API - the same one C applications
have.
to
dpdk::eal::init()
That is not current DPDK API.
Signed-off-by: Gregory Etelson <getel...@nvidia.com>
I'll get to a testing & review in the next days, however I'd like to ask some
bigger picture
questions, to understand/provide input on approach, and how big an effor to
expect here!
See above linked youtube video - I had sketched out some API concepts for
exposing a
"safe Rust API" wrapper around the DPDK C API, which also encodes threading
requirements.
Some questions:
- Is there an overaching "we're trying to achieve X with Rust", or specifically
"safe Rust"?
- Is this patch the "get DPDK + Rust working", with follow up patches for "safe
wrappers" the intention?
- Or is this patch all to expect for now?
The goal was to create RUST application over existing DPDK API.
The patch converts DPDK API files required for the helloworld example.
Additional API files will be added on demand.
Again, thanks for the patch, I think Rust is important for DPDK &
infrastructure software,
and will try make time to help test/review/discuss this patch, and the wider
Rust effort!
Regards, -Harry
<snip code itself>
Regards,
Gregory
