All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Van Haaren, Harry" <harry.van.haaren@intel.com>,
	Bruce Richardson <bruce.richardson@intel.com>,
	Gregory Etelson <getelson@nvidia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"mkashani@nvidia.com" <mkashani@nvidia.com>,
	"igootorov@gmail.com" <igootorov@gmail.com>,
	Stephen Hemminger <stephen@networkplumber.org>
Subject: Re: [PATCH v2] rust: support raw DPDK API
Date: Wed, 12 Mar 2025 18:19:55 +0100	[thread overview]
Message-ID: <3618203.GKX7oQKdZx@thomas> (raw)
In-Reply-To: <Z88SZddtUfSpTBhE@bricha3-mobl1.ger.corp.intel.com>

10/03/2025 17:25, Bruce Richardson:
> On Mon, Mar 10, 2025 at 04:13:21PM +0000, Van Haaren, Harry wrote:
> > 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).
> > 
> > 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.
> > 
> 
> Yes, definite +1 for this. Let's not try and have a half-C, half-Rust set
> of APIs, but instead let's have a clean low-level mapping directly to C
> functions, and then build a proper, safe API on top of that.

+1 about limiting this patch to a low-level unsafe binding,
while allowing a safe high-level API to be created later.




  reply	other threads:[~2025-03-12 17:20 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-06 13:37 [PATCH] rust: support DPDK API Gregory Etelson
2025-03-06 19:26 ` Van Haaren, Harry
2025-03-07 16:56   ` Etelson, Gregory
2025-03-07 15:54 ` Van Haaren, Harry
2025-03-07 16:20   ` Bruce Richardson
2025-03-07 18:15     ` Etelson, Gregory
2025-03-07 18:00   ` Etelson, Gregory
2025-03-08 14:28 ` Igor Gutorov
2025-03-08 19:14   ` Etelson, Gregory
2025-03-10 15:31     ` Stephen Hemminger
2025-03-12  5:21       ` Etelson, Gregory
2025-03-08 18:50 ` [PATCH v2] rust: support raw " Gregory Etelson
2025-03-10 16:13   ` Van Haaren, Harry
2025-03-10 16:25     ` Bruce Richardson
2025-03-12 17:19       ` Thomas Monjalon [this message]
2025-03-14 19:12     ` Etelson, Gregory
2025-03-10 15:00 ` [PATCH] rust: support " Stephen Hemminger
2025-03-12  5:12   ` Etelson, Gregory
2025-03-10 16:18 ` Stephen Hemminger
2025-03-10 16:30   ` Bruce Richardson
2025-03-12 14:30   ` Etelson, Gregory
2025-03-13  7:56     ` Igor Gutorov
2025-03-12 15:29   ` Igor Gutorov
2025-03-12 17:24     ` Thomas Monjalon
2025-03-14 18:38 ` [PATCH v3] rust: support raw " Gregory Etelson
2025-03-18  8:51   ` Dariusz Sosnowski
2025-03-18  9:12     ` Dariusz Sosnowski
2025-03-22 10:59 ` [PATCH v4] " Gregory Etelson
2025-03-22 17:39   ` Bruce Richardson
2025-03-27  5:51     ` Etelson, Gregory
2025-03-27 16:22   ` Bruce Richardson
2025-03-28 18:30     ` Etelson, Gregory
2025-03-27  8:23 ` DPDK for rust Morten Brørup
2025-03-27  9:00   ` Etelson, Gregory
2025-03-27 16:17     ` Bruce Richardson
2025-03-28 18:09       ` Etelson, Gregory
2025-03-28 19:25         ` Stephen Hemminger
2025-03-31  9:11           ` Bruce Richardson
2025-03-31 10:26             ` Luca Boccassi
2025-04-01 13:08               ` Etelson, Gregory
2025-03-31  9:03       ` Thomas Monjalon
2025-03-31  9:10         ` Bruce Richardson
2025-04-08 14:58 ` [RFC PATCH] add rust binding support to DPDK Bruce Richardson
2025-04-08 15:05   ` Bruce Richardson
2025-04-10  5:28   ` Etelson, Gregory
2025-04-11 13:13     ` Van Haaren, Harry
2025-04-11 15:39       ` Etelson, Gregory
2025-04-11 16:22         ` Van Haaren, Harry
2025-04-13  8:07           ` Etelson, Gregory
2025-04-13 17:09             ` Owen Hilyard
2025-04-17 11:11               ` Van Haaren, Harry

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=3618203.GKX7oQKdZx@thomas \
    --to=thomas@monjalon.net \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=getelson@nvidia.com \
    --cc=harry.van.haaren@intel.com \
    --cc=igootorov@gmail.com \
    --cc=mkashani@nvidia.com \
    --cc=stephen@networkplumber.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.