From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1790242BF1 for ; Mon, 5 Jun 2023 18:36:59 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7BD574021F; Mon, 5 Jun 2023 18:36:58 +0200 (CEST) Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) by mails.dpdk.org (Postfix) with ESMTP id E970F4003C; Mon, 5 Jun 2023 18:36:56 +0200 (CEST) Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-565eaf83853so55319217b3.3; Mon, 05 Jun 2023 09:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685983016; x=1688575016; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DQeHKoQlJbVmELKYO5E7EQbI8abT4xifT/U9Z09jQDc=; b=R83yKWuUDlQPuTy1GdqTtJVfnULhsp+qdSz0EEk7fx+fLmzBSnEtlwGEUjv0+vMRn9 GqrLv6quI74P2mdIi/pXo9pP5ktHlkzp2/R1zsqPTJvRvK+eAsLn+y8CwvestCAxl36m 9IwSBjp4bGVDwR2JLbKpHMYYSo3e1iUt1SFWU9MfyfteQ8m+ML7cmo1E5Zwm2HvcCfgO B1woGQCFvpcUc+C4j6huzMj0UnIMUkdfUrhKFr5zQPICUH7KnaQ2M8Tr0SnyAa12yFBV OiLcbGOauJcyL1hKJiGFQ5YmPrzMeh0xVXtS+5uKaJQUH09sj/nyY3POc4+Tf8bFxp9Q J05w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685983016; x=1688575016; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DQeHKoQlJbVmELKYO5E7EQbI8abT4xifT/U9Z09jQDc=; b=a7dlgfKIiyxc1fWXH7K/ma+P4+IRFw1TuU65so5cVlJXURKfdwwgvPVGc/oyX75+c3 sDk8IBOsI32Cw++b8KlDAVDQh19CEMh2UcpC8FXcZ8MMNUcQIAjNttHd3olTDbAUV4zK n26tvcCnpERSg73k+bjLZ67i9RW3ZVfBHvpTZwXsdF8Hz1ojziEUI9qaWIPWxR6U2ocW 7BFqKZIDmRX0iCYobdAR31UDZPV5HELrP85mmyEoW3xaVvomemWn+WiygbFH4qENQNxW vQB8mUgLewPqfwQgnVi86iVVfN2/eZhym+4SnbtGl4joOviQ40/JiTdB3CN4eB+1WqWS mJ9g== X-Gm-Message-State: AC+VfDzm++gINFoyh5ewsqzMQXmlANU+7+fjoRCURtRDiEJ9C80ZewYn 7/C97iWtN5mtceIZT9+FYLkXEtCGEcI2+jXKLMw= X-Google-Smtp-Source: ACHHUZ7gEPO0cXr7c/4nxXd6Dnr3UsQ4J/o2IuI22uSauTeV9AWDI+mRp2qujKbAEZSspp/Z8leh2b3oFoWtSV0jBvI= X-Received: by 2002:a0d:dec7:0:b0:569:770d:c9be with SMTP id h190-20020a0ddec7000000b00569770dc9bemr8630262ywe.41.1685983016147; Mon, 05 Jun 2023 09:36:56 -0700 (PDT) MIME-Version: 1.0 References: <20230428170446.122c8775@hermes.local> <16663033.Ash8RoxBsO@thomas> In-Reply-To: <16663033.Ash8RoxBsO@thomas> From: kumaraparameshwaran rathinavel Date: Mon, 5 Jun 2023 22:06:44 +0530 Message-ID: Subject: Re: Generic flow string parser To: Thomas Monjalon Cc: Cliff Burdick , Tom Barbette , Stephen Hemminger , David Marchand , users , Ori Kam , dev@dpdk.org Content-Type: multipart/alternative; boundary="000000000000c661be05fd64825d" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --000000000000c661be05fd64825d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 30, 2023 at 3:10=E2=80=AFAM Thomas Monjalon wrote: > 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 testpm= d > > came from. Writing a new parser is obviously the better choice and woul= d > > have been great if testpmd started that way, but a significant amount o= f > > 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 th= e > > 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=E2=80=AFPM Stephen Hemminger < > > stephen@networkplumber.org> wrote: > > > > > On Fri, 28 Apr 2023 12:13:26 -0700 > > > Cliff Burdick 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 fl= ow > > > > 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 woul= d > 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? > > >> +1 It would be definitely useful to have a generic parser which could >> re-use the test-pmd parser code as it has already done the heavy lifting= . I >> would be happy to contribute/help to get this going. >> > --000000000000c661be05fd64825d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Apr 30, 2023 at 3:10=E2=80=AF= AM Thomas Monjalon <thomas@monjal= on.net> wrote:
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 co= ded
> > 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 t= estpmd
> came from. Writing a new parser is obviously the better choice and wou= ld
> 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 did= n'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 t= he parser
> piece, but also making sure all the tests now use that, and also the l= egacy
> 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 t= he
> amount of debugging I (and others) have spent on figuring on why a flo= w
> 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=E2=80=AFPM Stephen Hemminger <
> stephe= n@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 almos= t everything needed,
> > > something like that could be exposed. If we think of the tes= tpmd flow
> > > string as a sort of "IR" for string flow specifica= tion, 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 g= reat of an ask to
> > > have testpmd support a new type of parsing. My only suggesti= on would be
> > > to take what already exists and expose it in a public API th= at 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?


+1 It = would be definitely useful to have a generic parser which could re-use the = test-pmd parser code as it has already done the heavy lifting. I would be h= appy to contribute/help to get this going.
--000000000000c661be05fd64825d--