<snip>
Looking at the above parts of "Port abstraction in Rust", I'm not sure it
really adds anything.
It feels a bit "middle of the road" (aka, adding some "abstraction", but not
going far enough).
Current helloword example is a POC for the raw module usage.
It content can (should) be updated once the API will be more stable.
What if we took an even smaller step: remove the Rust struct concepts, and just call the
"dpdk::raw::*" unsafe
functions directly, as if they were C code. No "struct Port, impl Port", and no
"Iterator<DpdkPort" concepts at all.
That would show "correct" usage of the raw generated bindings, and provide raw
API unit-tests.
In cases when helloworld is activated with more than 1 port, dedicated
structure helps to keep track of resources.
Maybe that example was not the best choice for "helloworld" introduction.
In a future patch, we can start to build "Safe Rust" essential-basics of EAL,
and Ethdev. This is to abstract over the
"dpdk::raw::*" APIs, "compiles == correct", end-user documentation, etc all as
is normal in Rust ecosystem. Example:
Today: V2 patch (note the "Port" struct in Rust):
pub unsafe fn init_port_config(port: &mut Port) { ... }
Future Raw API (note the raw u16 like C APIs):
unsafe fn init_port_config(port: u16) { ... }
Future Safe API (mockup, this needs thought):
let ports = eal.get_eth_ports();
for p in &mut ports {
p.initialize(rxqs, txqs, ...)?;
}
Thoughts?
The raw API links rust application directly with DPDK libraries.
Such application can achieve the same performance as C application.
DPDK can have additional rust module - dpdk::native, for genuine rust
interfaces.
With 2 rust modules, DPDK users will have time to build application logic
while DPDK developers can safely experiment with new API.
I see the raw module as a temporal solution before DPDK will have native rust
API.
Regards,
Gregory
