Hello Bruce,
Thanks for sharing. However, IMHO using EAL for thread management in rust
is the wrong interface to expose.
EAL is a singleton object in DPDK architecture.
I see it as a hub for other resources.
Following that idea, the EAL structure can be divided to hold the
"original" resource
Hello Harry,
> I implemented a working echo server with your API.
> The code is here: https://github.com/getelson-at-mellanox/rdpdk/tree/safe-q
Ah cool! Great to see the API working.
Reviewing the "echo.rs" code, the MbuffMempoolHandle ergonomics can perhaps be
improved,
I'll try work on that
Hello Harry,
Thank you for sharing the API.
Please check out my comments below.
Regards,
Gregory
On Thu, 17 Apr 2025, Harry van Haaren wrote:
External email: Use caution opening links or attachments
This patch is NOT to be considered for merge, it is a demo
of the Rust APIs for Ethdev. Ther
Hello Harry,
Thanks for posting this RFC. I'll share my API RFC in the coming days too, for
now
some feedback (which is already integrated/existing in the API I've been
working on)
Bigger picture; the APIs below implement "DPDK C API thinking" in Rust. I'd like to
rework the APIs to be "DPD
Hello Harry,
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
A
Hello Bruce & Harry,
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 to
Hello Bruce,
Add a Cargo.toml file in the root folder and a number of other scripts
and rust-related files into buildtools/rust, which then enables DPDK to
be cloned and built as a rust crate - all-be-it one with only two
functions: rte_eal_init and rte_eal_cleanup.
Signed-off-by: Bruce Richard
Hello,
I pulled the raw library bindings out of DPDK source into a dedicated crate and
cleaned up compilation warnings.
Also I started a testpmd like application - runpmd.
At this stage it can receive buffers and insert flows with very limited items
and actions coverage.
The total patches a
Hello Bruce,
When using bindgen, are we better to take the approach (as in this patch)
of running it on everything in the headers and just excluding some things,
or taking the opposite conservative approach of just listing the functions
and defines we actually do want exposed (with wildcarding
Hello Morten,
Thank you for raising these questions !
Do we want the DPDK project itself to support rust?
Or should parts of this be a DPDK hosted project, like grout?
Rust packages management is different.
Also DPDK Rust code will eventually provide a different API.
At this stage, DPDK host
Hello Morten,
Thank you for raising these questions !
Do we want the DPDK project itself to support rust?
Or should parts of this be a DPDK hosted project, like grout?
Rust packages management is different.
Also DPDK Rust code will eventually provide a different API.
At this stage, DPDK host
Hello Bruce,
Hi Gregory, some high-level feedback:
* I'd suggest for future revisions splitting this into two patches. The rust
example should be separate from a patch adding the basic rust
infrastructure.
In progress.
* For the example, I'd suggest that the helloworld rust example should
+[dependencies]
+dpdklib = {path = "MESON_INSTALL_DESTDIR_PREFIX/rust"}
\ No newline at end of file
Bad practice.
Don't forget EOL
I'll fix that
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
Re-implementing test-pmd, l3fwd, etc in Rust is OK but not huge leap.
DPDK examples and applications are part of inner infrastructure.
The patch allows external RUST application as well.
The real benefit would the ability to support PMD's built in Rust.
That would be much more invasive
It
There is no DPDK API for RUST yet.
My patch allows RUST application to use native DPDK API.
I'll adopt you coding style suggestions in the next patch release.
I have same concerns about rust in DPDK as the Linux kernel.
What API's are we going to be covered?
The plan is to convert API in dem
Hello Igor,
Hi Gregory!
As a DPDK as well as a Rust user, I'm quite excited about this patch.
I'm wondering though, is DPDK getting an official Rust API? I'm
subscribed to dev and user mailing lists, and haven't seen any
announcements - did I miss something?
Bellow are some stylistic suggestio
On Fri, 7 Mar 2025, Bruce Richardson wrote:
External email: Use caution opening links or attachments
On Fri, Mar 07, 2025 at 03:54:33PM +, Van Haaren, Harry wrote:
From: Gregory Etelson
Sent: Thursday, March 6, 2025 1:37 PM
To: dev@dpdk.org
Cc: getel...@nvidia.com ; tho...@monjalon.n
On Fri, 7 Mar 2025, Van Haaren, Harry wrote:
External email: Use caution opening links or attachments
From: Gregory Etelson
Sent: Thursday, March 6, 2025 1:37 PM
To: dev@dpdk.org
Cc: getel...@nvidia.com ; tho...@monjalon.net ;
mkash...@nvidia.com ; Richardson, Bruce
Subject: [PATCH] ru
Hello Harry,
From: Gregory Etelson
Sent: Thursday, March 6, 2025 1:37 PM
To: dev@dpdk.org
Cc: getel...@nvidia.com ; tho...@monjalon.net ;
mkash...@nvidia.com ; Richardson, Bruce
Subject: [PATCH] rust: support DPDK API
Cool, I like this subject, great!
The patch converts include files w
Hello Stephen,
Did you consider that most of the hairpin_conf values could just be set
directly,
avoiding intermediate variables.
fixed.
+ diag = rte_eth_rx_hairpin_queue_setup
+ (pi, qi, nb_rxd, &hairpin_conf);
fixed.
Hello Stephen,
+static __rte_always_inline
+char *parse_hairpin_map_entry(char *input, char **next)
+{
+ char *tail = strchr(input, ':');
+
+ if (!tail)
+ return NULL;
+ tail[0] = '\0';
+ *next = tail + 1;
+ return input;
+}
+
There is no reason to mark this as
On Fri, 20 Sep 2024, Singh, Aman Deep wrote:
External email: Use caution opening links or attachments
Hi Gregory,
Can you please resolve the compilation issues seen with this patch.
Hello,
I've posted v5.
Regards,
Gregory
Hello,
The mbuf structure [1] has __extension__ here,
i.e. preceding the structure following the integer field,
instead of preceding the union.
[1]: https://git.dpdk.org/dpdk/tree/lib/mbuf/rte_mbuf_core.h#n520
+1 anonymous unions are standard C so __extension__ is not necessary, it
is necessa
Hello,
I've posted v2 patch with fixes.
Regards,
Gregory
Hello Stephen,
Basic question, what would be the impact of increasing the default from 512
to 1k or 2k? Do we get a large memory footprint increase, or is it just an
extra 1 or 2k of memory used?
/Bruce
Increasing the RDLINE_BUF_SIZE size will also increase application memory usage.
However,
Hello Bruce,
Application can set custom cmdline size during DPDK configuration:
`meson setup ... -Dc_args='-DRDLINE_CUSTOM_BUF_SIZE=4096' ...`
Signed-off-by: Gregory Etelson
---
Basic question, what would be the impact of increasing the default from 512
to 1k or 2k? Do we get a large memory
Hello Ferruh,
<...>
Syntax above is odd, why not move parenthesis to first line.
Agree that's odd style.
DPDK prefers that way.
Please check rte_flow_driver.h::rte_flow.ops.
True that is also odd but at least it is function pointers in a struct,
but this is regular function deceleration, w
Hello Ferruh,
Having conflict while applying the patch, can you please rebase it on
latest 'next-net'?
Will rebase and update the patch.
+Query wheather template table can be resized.
s/wheather/whether/
<...>
fix in updated patch
+__rte_experimental
+bool
+rte_flow_template
Hello Ferruh,
I have two more clarification requests, can you please check them below?
If one ore more flow failed to update, for any reason, should user retry
the update (in that case we need a retry error maybe) and can user still
call 'rte_flow_template_table_resize_complete()' (for possi
Hello Thomas,
+
+ # 1. Create resizable template table for 1 flow.
+ testpmd> flow pattern_template 0 create ingress pattern_template_id 3
+template eth / ipv4 / udp src mask 0x / end
+ testpmd> flow actions_template 0 create ingress actions_template_id 7
+
Hello Ferruh,
I work on the patch update with detailed user guide for
the table resize API.
Regards,
Gregory
So, by design, driver will keep the old table when it is resized.
- Can this have a performance impact, like when rules
updated/removed/inserted driver will need to look more tables?
-
Hello Thomas,
--- a/lib/ethdev/rte_flow.h
+++ b/lib/ethdev/rte_flow.h
#define RTE_FLOW_TABLE_SPECIALIZE_TRANSFER_VPORT_ORIG RTE_BIT32(1)
+/**
+ * Specialize table for resize.
+ */
+#define RTE_FLOW_TABLE_SPECIALIZE_RESIZABLE_TABLE RTE_BIT32(2)
I'm not sure about the repeating "TABLE" at the e
Hello Patrick,
External email: Use caution opening links or attachments
Thank you for sharing Gregory. I did not get an opportunity to look through the
code today, but I did run
through the presentation. A few points I noted:
1. The presentation shows an example testpmd testcase for creating a
Hello Ferruh,
Template table creation API sets table flows capacity.
If application needs more flows then the table was designed for,
the following procedures must be completed:
1. Create a new template table with larger flows capacity.
2. Re-create existing flows in the new table and delete flo
Hello Ferruh,
So, by design, driver will keep the old table when it is resized.
- Can this have a performance impact, like when rules
updated/removed/inserted driver will need to look more tables?
- Or can this cause additional capacity complexity, like total number of
rules will be sum of rules
Hello Ferruh,
If a multi-threaded application can add new and updated old
simultaneously, this should be done via monolithic API, like:
{
lock
resize
unlock
for each flow
lock
update
unlock
}
The flow template API was designed for performance.
Application that implements the f
Hello Ferruh,
Hi Gregory, Ori,
Why we need three separate APIs,
rte_flow_template_table_resize
rte_flow_async_update_resized
rte_flow_template_table_resize_complete
Why not 'rte_flow_template_table_resize()' update existing flows and
release resources related to the original tables automatica
Hello Luca,
Your proposal sounds rather interesting. Certainly enabling DTS to
accept YAML-written tests sounds more developer-friendly and should
enable quicker test-writing. As this is an extra feature though – and a
nice-to-have, it should definitely be discussed in the DTS meetings as
Honnap
Hello Honnappa,
[snip]
Hi Gregory,
I do not fully understand your proposal, it will be helpful to join the
DTS meetings to discuss this further.
Agree, let's discuss the proposal details during the DTS meeting.
YAML has wide support built around it. By using our own text format, we
Hello,
Consider an option to describe DTS test with testpmd and SCAPY plain text
commands.
For example:
Scenario:
- Configure UDP packet in SCAPY and a flow in testpmd.
- Send UDP packet and validate testpmd output triggered by that packet.
```yaml
phase_0:
name: CONFIGURATION
tg:
Hello Tyler,
since we are duplicating something that comes from something else that
has been duplicated out of windows WDK here it might be a reasonable
safety check to verify that our duplicated values match our
expectations?
MEM_COALESCE_PLACEHOLDERS, MEM_PRESERVE_PLACEHOLDER,
MEM_REPLACE_P
Hello Tyler,
since we are duplicating something that comes from something else that
has been duplicated out of windows WDK here it might be a reasonable
safety check to verify that our duplicated values match our
expectations?
MEM_COALESCE_PLACEHOLDERS, MEM_PRESERVE_PLACEHOLDER,
MEM_REPLACE_P
Hello Ferruh,
About the fault root cause.
There were 2 uncoupled resources in that case: static token size and
variable size passed to parse_int().
parse_int() caller must provide a buffer large enough for token size.
Otherwise parse_int() will corrupt memory outside the input buffer.
As you
Hello Ferruh,
[:snip:]
*** stack smashing detected ***: terminated
The corruption occurred in `parse_int()` called from
`parse_indlst_id2ptr()`.
Inside `parse_int()` the arg parameter referenced 8 bytes of memory
while the target buffer was 4 bytes allocated on caller optimized stack:
(gdb)
Hello Ferruh,
Indirect actions list arguments parser was configured to place target
number into 64bit value, while the code provided 32bits memory.
Hi Gregory,
Can you please give more details why 'id' needs to be 64 bits, with
callstack or usecase etc?
And please describe what is the observ
Hello Ferruh,
Indirect actions list arguments parser was configured to place target
number into 64bit value, while the code provided 32bits memory.
Hi Gregory,
Can you please give more details why 'id' needs to be 64 bits, with
callstack or usecase etc?
And please describe what is the observ
On Sun, 5 Nov 2023, Thomas Monjalon wrote:
External email: Use caution opening links or attachments
The description of this patch does not match the change.
Also the change is going backward, using deprecated fields.
It does not make sense, I'll skip it.
Hello Thomas,
Patches in that s
48 matches
Mail list logo
