DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Van Haaren, Harry" <harry.van.haaren@intel.com>
To: Gregory Etelson <getelson@nvidia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"owen.hilyard@unh.edu" <owen.hilyard@unh.edu>
Subject: Re: [PATCH] rust: RFC/demo of safe API for Dpdk Eal, Eth and Rxq
Date: Thu, 24 Apr 2025 16:06:29 +0000	[thread overview]
Message-ID: <PH8PR11MB680363E200616CBB39DDDCB6D7852@PH8PR11MB6803.namprd11.prod.outlook.com> (raw)
In-Reply-To: <IA1PR12MB63308A2F69036E3ACCC605D0A5B92@IA1PR12MB6330.namprd12.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 2620 bytes --]

> From: Gregory Etelson
> Sent: Sunday, April 20, 2025 9:57 AM
> To: Van Haaren, Harry
> Cc: dev@dpdk.org; Richardson, Bruce; owen.hilyard@unh.edu
> Subject: Re: [PATCH] rust: RFC/demo of safe API for Dpdk Eal, Eth and Rxq
>
> 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 and have some API suggestions to the mailing list soon.

I see the echo.rs code uses a normal "std::thread::spawn" (not DPDK lcores), there is
some design to do here to ensuring that best practices are used;
- any dataplane threads are registered as lcores (for best performance, mempool caches etc)
- registered lcores are also unregistered when a thread ends (potentially allowing lcore-id reuse??)
I haven't thought about this much, but had a brief discussion with Bruce (who is on holidays now).

Suggesting that mempools & lcores are the two next up API sets to "Rustify" :)


> Several changes:
> DPDK configuration is split to 3 mandatory steps:
> port configuration in
> Port::configure(&mut self, rxq_num: u16, txq_num: u16) -> Result<(), String>
> Rx queues configuration in
> Port::config_rxqs(&mut self, desc_num: u16, mempool: DpdkMempool) -> Result<(), String>
> Tx queues configuration in
> Port::config_txqs(&mut self, desc_num: u16) -> Result<(), String>
> In the IO thread, I renamed the `enable_polling()` to `activate()` for Rx/Tx symmetry.
> I renamed `port` and `q` struct members to `port_id`, `queue_id`

Those seem reasonable changes; no particular concerns.
We can do always do "more more more" type-safety in making it impossible to mis-configure (at compile time).
While type-safety is nice, it will complicate the code too: finding the right tradeoff is key.

For me, having the "Rxq" be pollable only from the correct thread (compile-time check) is the most valuable.
The configuration is "nice to have", but good/simple examples will help users start quickly too, particularly
if the APIs are simple.


> Build steps:
>
> Apply https://github.com/getelson-at-mellanox/rdpdk/blob/safe-q/dpdk-patches/0001-rust-export-missing-port-objects.patch to DPDK source.
> Install DPDK
> Set PKG_CONFIG_PATH to DPDK installation
>
> Activation:
>
> # cargo run --example echo -- -a <port PCI address>

I haven't tried these steps yet, sorry (lack of time at the moment).

> Regards,
> Gregory

Thanks again! -Harry

[-- Attachment #2: Type: text/html, Size: 13800 bytes --]

  reply	other threads:[~2025-04-24 16:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-17 15:10 Harry van Haaren
2025-04-17 18:58 ` Etelson, Gregory
2025-04-18 11:40   ` Van Haaren, Harry
2025-04-20  8:57     ` Gregory Etelson
2025-04-24 16:06       ` Van Haaren, Harry [this message]
2025-04-27 18:50         ` Etelson, Gregory
2025-04-18 13:23 ` [PATCH 1/3] " Harry van Haaren
2025-04-18 13:23   ` [PATCH 2/3] rust: split main into example, refactor to lib.rs Harry van Haaren
2025-04-18 13:23   ` [PATCH 3/3] rust: showcase port Rxq return for stop() and reconfigure Harry van Haaren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=PH8PR11MB680363E200616CBB39DDDCB6D7852@PH8PR11MB6803.namprd11.prod.outlook.com \
    --to=harry.van.haaren@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=getelson@nvidia.com \
    --cc=owen.hilyard@unh.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).