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 64FD042A16 for ; Sat, 29 Apr 2023 16:23:42 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BF0C340A7D; Sat, 29 Apr 2023 16:23:41 +0200 (CEST) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by mails.dpdk.org (Postfix) with ESMTP id 61D914067E for ; Sat, 29 Apr 2023 16:23:40 +0200 (CEST) Received: by mail-io1-f46.google.com with SMTP id ca18e2360f4ac-768d75b2369so73395339f.0 for ; Sat, 29 Apr 2023 07:23:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682778219; x=1685370219; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=L4cVwMixF9hNuRCuc9NnWBdtSVqgq/LZzm7Cj6bRcI4=; b=YXxudz8MLjWdp7A8TNuKypiWtG30uClKUoe/IV6eZzxGQ4VZY7TD6+8rCgJZVelS6P tJASAV/Es0aGh7t1ukCKkFBtQSKy6gd77g/fX/61XiZ6HqE0x9FoNbIw8OgY6GjmG5nZ NsmqwnG5y9YJz0WwJe/L3MbyClKUN0lQHj8Ws5Zp8Xk002tCqziRZ0IGT97QulemH8qs DpHRKWlVDsZu1cAK9yOA15nf2IDAFM+UARimUkYJdza+sGMPjgWrXjjrWsVm4nF1cUtX o2liwomnIVlfRpgyLmv1Dximhz3UntTlfruL17GKpALQ+2f+lV2fm9t4TTguaUZwKgLr 9z8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682778219; x=1685370219; 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=L4cVwMixF9hNuRCuc9NnWBdtSVqgq/LZzm7Cj6bRcI4=; b=Ppjn5Mi2wG4NZeME5X++UsiA6wVG9bqbTLmScNVeci7xO86l9imVXfCjIZrEhRfHs+ 2L6O2EL6kiP/DLSju87h1OfI5mvy2tXfZQ7qjiurzYeIxrUlVdRRrMlz8wyGDZ3nDE39 ycxZxKgYRt3sM3wLU/P1TO1eCYc31f0AYTssGCX/9d/rWTwmwbn32QLDyjfY8lRwBvXk kDG/DuhBJK9v25uvGEMsto3hm0jjL6+B5CMSQ6CwOozHrIbo7Hv1Ig3XfOhCYNSVkfUt xNuSNX7uE41y9masPgEmVC8UWPrQUOfRBBzVXrSPn0WXGXDmDUvFDidnSl+Qq2SymAR9 NpaA== X-Gm-Message-State: AC+VfDxmEzLGGXiDtXxSWBLYErWZfDBSJu0X3hc8WUva33v0NWJ2F1tk KNmdIZJYZvmCI/eusYlP4cB3y5W8zshv/sB04vI= X-Google-Smtp-Source: ACHHUZ4q99ny5cx6p7ocn+rkml45pVee2onQeCyza4UrMRdENODdFr9n1bBhoC0yQEqOgb3jTV/ekjET14OUrvhWGMs= X-Received: by 2002:a05:6602:146:b0:763:68b7:23d2 with SMTP id v6-20020a056602014600b0076368b723d2mr4809438iot.21.1682778219515; Sat, 29 Apr 2023 07:23:39 -0700 (PDT) MIME-Version: 1.0 References: <1814734.QZUTf85G27@thomas> <771fa709-563f-1ec2-a997-084b7709edce@uclouvain.be> <20230428110935.00311cd8@hermes.local> <20230428170446.122c8775@hermes.local> In-Reply-To: <20230428170446.122c8775@hermes.local> From: Cliff Burdick Date: Sat, 29 Apr 2023 07:23:27 -0700 Message-ID: Subject: Re: Generic flow string parser To: Stephen Hemminger Cc: Tom Barbette , Thomas Monjalon , David Marchand , users , Ori Kam Content-Type: multipart/alternative; boundary="0000000000000295f705fa7a56b8" 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 --0000000000000295f705fa7a56b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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=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 ther= e > > 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 allo= w > > others to implement higher-level transform of a schema like JSON or YAM= L > > 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. > > > > If you look at the "flow_classify" example in DPDK you can already see > that > > for that application someone had to write another flow text parser for = a > > format they made up. Instead, that example could be converted over to > this > > other API as well. > > Please don't top post. > > The naming issue is that almost all libraries in DPDK start with rte_ > prefix > and the testpmd functions do not. > > The flow_classify example is pretty much abandonware at this point. > Code is not updated, other than build breakages. > Last time I looked at it noticed lots of code reinvention useless code, > and only supports IPv4. It really needs a rewrite. > --0000000000000295f705fa7a56b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Would rather the flow parser was rewritten as well. D= oing 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 u= sing 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 a= mount 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 i= nto an rte_ API. I'd imagine building a proper parser would not just re= quire the parser piece, but also making sure all the tests now use that, an= d also the legacy testpmd was converted. It seemed unlikely all of this cou= ld be done in=C2=A0a reasonable amount of time and a lot of input from many= people. Given the amount of debugging I (and others) have spent on figurin= g on why a flow spec didn't work properly, this could be a huge timesav= er 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 <s= haklee3@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 everythi= ng needed,
> something like that could be exposed. If we think of the testpmd flow<= br> > 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 YA= ML
> 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 b= e to
> take what already exists and expose it in a public API that is include= d in
> a DPDK install.
>
> If you look at the "flow_classify" example in DPDK you can a= lready see that
> for that application someone had to write another flow text parser for= a
> format they made up. Instead, that example could be converted over to = this
> other API as well.

Please don't top post.

The naming issue is that almost all libraries in DPDK start with rte_ prefi= x
and the testpmd functions do not.

The flow_classify example is pretty much abandonware at this point.
Code is not updated, other than build breakages.
Last time I looked at it noticed lots of code reinvention useless code,
and only supports IPv4. It really needs a rewrite.
--0000000000000295f705fa7a56b8--