Hello Bruce & Harry,
<snip>
My concern is how to properly maintain Rust crate once DPDK starts to implement
it's own API.
I'm not really sure what is meant here. I don't understand what "own" word
refers to?
I see it like this:
- DPDK has the public C API exported (and that stays the same as today, with
ABI rules, version.map files, etc)
- The Rust crate consumes the public C API (via bindgen, as done in this patch.
More detail about bindgen below.)
Bindgen cannot provide access to all DPDK public API.
A good example here is rte_eth_rx_burst().
That function is defined as inline and bindgen does not translate it.
Also, the function definition references rte_eth_fp_ops array that is not part of the
public DPDK API. That means Rust cannot duplicate rte_eth_rx_burst() "as-is" and
the solution can require extensions to existing DPDK API.
I added a new public API that exports rte_eth_fp_ops for a given port Id.
Rust implementation of rte_eth_rx_burst() does not have to follow the original
approach.
Usage of rte_eth_fp_ops is good for C, but Rust has different methods.
For conclusion, Rust DPDK infrastructure cannot relay on bindgen only and needs
to provide native implementation for some public DPDK API.
It can be easier to maintain Rust files separately.
You can check out my Rust DPDK version here:
https://github.com/getelson-at-mellanox/rdpdk
<snip>
Next steps are to "allowlist" more DPDK public API functions, and start building
"Safe Rust" APIs over
them, in order to expose an ergonomic and misuse-resistant API. As you note,
this is where a network ports,
lcores, mempools, and ethdev configuration are all required. First goal something like
"Safe L2 macswap"?
I suggest to set the first goal to initiate a port and run simple Rx/Tx
functions.
I will make some Safe-Rust API suggestions for EAL, and send a patch sometime
next week to discuss.
Thanks for the inputs! Regards, -Harry
Regards,
Gregory
