DPDK usage discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Cliff Burdick <shaklee3@gmail.com>,
	Tom Barbette <tom.barbette@uclouvain.be>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	David Marchand <david.marchand@redhat.com>,
	users <users@dpdk.org>, Ori Kam <orika@nvidia.com>,
	dev@dpdk.org
Subject: Re: Generic flow string parser
Date: Sat, 29 Apr 2023 23:39:57 +0200	[thread overview]
Message-ID: <16663033.Ash8RoxBsO@thomas> (raw)
In-Reply-To: <CA+Gp1naKMx3dFut3qYwnZNUOaTs9VqCCYrC9EkxjnUgBLenKUw@mail.gmail.com>

This thread is an API suggestion, it should be discussed in
the developer mailing list (did the Cc here).

29/04/2023 16:23, Cliff Burdick:
> > Would rather the flow parser was rewritten as well. Doing open coded
> > parser is much more error prone and hard to extend versus writing the
> > parser in yacc/lex (ie bison/flex).
> 
> I agree, and that's kind of why the original suggestion of using testpmd
> came from. Writing a new parser is obviously the better choice and would
> have been great if testpmd started that way, but a significant amount of
> time was invested in that method. Since it works and is tested, it didn't
> seem like a bad request to build off that and bring that code into an rte_
> API. I'd imagine building a proper parser would not just require the parser
> piece, but also making sure all the tests now use that, and also the legacy
> testpmd was converted. It seemed unlikely all of this could be done in a
> reasonable amount of time and a lot of input from many people. Given the
> amount of debugging I (and others) have spent on figuring on why a flow
> spec didn't work properly, this could be a huge timesaver for new projects
> like Tom mentioned.
> 
> On Fri, Apr 28, 2023 at 5:04 PM Stephen Hemminger <
> stephen@networkplumber.org> wrote:
> 
> > On Fri, 28 Apr 2023 12:13:26 -0700
> > Cliff Burdick <shaklee3@gmail.com> wrote:
> >
> > > Hi Stephen, it would definitely not be worthwhile to repeat everything
> > > that's already tested with testpmd. I was thinking that given that there
> > > already is a "flow_parse" function that does almost everything needed,
> > > something like that could be exposed. If we think of the testpmd flow
> > > string as a sort of "IR" for string flow specification, that would allow
> > > others to implement higher-level transform of a schema like JSON or YAML
> > > into the testpmd language. Due to the complexity of testpmd and how it's
> > > the source of true for testing flows, I think it's too great of an ask to
> > > have testpmd support a new type of parsing. My only suggestion would be
> > > to take what already exists and expose it in a public API that is included
> > > in a DPDK install.

So the only things we need are 2 functions, if I understand well:

int rte_flow_to_text(const struct rte_flow*);
struct rte_flow *rte_flow_from_text(const char *);

Here I assume the output of rte_flow_from_text() would be a created flow,
meaning it calls rte_flow_create() under the hood.
Is it what you wish?
Or should it fill port ID, attributes, patterns and actions?



  reply	other threads:[~2023-04-29 21:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-26  4:46 Cliff Burdick
2023-04-26  5:47 ` David Marchand
2023-04-27  8:37   ` Thomas Monjalon
2023-04-27 13:19     ` Cliff Burdick
2023-04-28 17:36       ` Tom Barbette
2023-04-28 18:09         ` Stephen Hemminger
2023-04-28 19:13           ` Cliff Burdick
2023-04-29  0:04             ` Stephen Hemminger
2023-04-29  0:08               ` Stephen Hemminger
2023-04-29 14:23               ` Cliff Burdick
2023-04-29 21:39                 ` Thomas Monjalon [this message]
2023-04-29 21:49                   ` Cliff Burdick
2023-05-26 22:35                     ` Cliff Burdick
2023-06-05 16:36                   ` kumaraparameshwaran rathinavel

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=16663033.Ash8RoxBsO@thomas \
    --to=thomas@monjalon.net \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=orika@nvidia.com \
    --cc=shaklee3@gmail.com \
    --cc=stephen@networkplumber.org \
    --cc=tom.barbette@uclouvain.be \
    --cc=users@dpdk.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 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).