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 A87E142A19; Sat, 29 Apr 2023 23:40:03 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 31F0340E01; Sat, 29 Apr 2023 23:40:03 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id F0B3640A7D; Sat, 29 Apr 2023 23:40:01 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 44BA05C0150; Sat, 29 Apr 2023 17:40:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sat, 29 Apr 2023 17:40:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1682804401; x=1682890801; bh=6PGAxtqKuNvkS3IkNx2KQeP0bBkHbtXNSc0 ayGJfMOw=; b=ZSQyZ4I2AMnt+azTrjh9lAslCJ7/Xc9Gz06f3yYogUjzHISMrOI qJc10Jz2OWjV3XLhh8twEvwR9cQ8B7+GLRGsSJ7skvLVGdMmsCVJBA1/ybqeYhpz I1lXwbbnVmGHEuITbqT+jceCp7IiNwD3mITejt0LEpkHZn1DrSjdl0R3qKORKups +zrVKUIJzD/aUoDiroYlK4gZCgZfzKtinMYYJ2lLTQ8DOq4/uLcz+wATxW5eap4d zc6OA9WzOMv2BcCshRnNBHGB7moTXNxhroFSUh4Y2aixQmbSTjwtibWueYXzN1wB adBr/SSoJMPn7LX+L7fmhE0khduWyryp/mw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1682804401; x=1682890801; bh=6PGAxtqKuNvkS3IkNx2KQeP0bBkHbtXNSc0 ayGJfMOw=; b=XJhHZuxEZgve5wLh0gOzmT39JNlSWRfqQLIIIrULXo3MmyYCxL8 LqRdNIib4NHeC8ZavFzFfnqQCEc+Dt+jmISPPiCueoUGnC6t2o/u0MoQP2EysAoK cMBPop/LVqONZh/tAE1jr+22ODgYTXbe3ytFbyQ3vpzw/88meLQchjCkdbl0oWEl M9KBh2VqbyuC3uHGqPG+QDYZxhxBaVqPG8IFa04gQ+qtYolMFL/PBDWEISgGmA60 inoxIECp7pk2DhVEnL9HQa2iHKwnAqDLTBJ25psJfpJfHZ9NaXf3zo73xRb7sh1o ZDWbdZ9LxvKoUWrOKAY02XImcBXqD6PKTGA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedvtddgudegtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhho mhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqne cuggftrfgrthhtvghrnhepgedttdeljeejgeffkeekkedtjeevtdehvedtkeeivdeuuedv ieduvdelveejueejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 29 Apr 2023 17:39:59 -0400 (EDT) From: Thomas Monjalon To: Cliff Burdick , Tom Barbette Cc: Stephen Hemminger , David Marchand , users , Ori Kam , dev@dpdk.org Subject: Re: Generic flow string parser Date: Sat, 29 Apr 2023 23:39:57 +0200 Message-ID: <16663033.Ash8RoxBsO@thomas> In-Reply-To: References: <20230428170446.122c8775@hermes.local> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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). >=20 > 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 pars= er > piece, but also making sure all the tests now use that, and also the lega= cy > 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. >=20 > On Fri, Apr 28, 2023 at 5:04=E2=80=AFPM Stephen Hemminger < > stephen@networkplumber.org> wrote: >=20 > > 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 th= ere > > > 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 al= low > > > others to implement higher-level transform of a schema like JSON or Y= AML > > > into the testpmd language. Due to the complexity of testpmd and how i= t's > > > the source of true for testing flows, I think it's too great of an as= k 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 inc= luded > > > 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?