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 C904442BAD for ; Sat, 27 May 2023 00:35:50 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5D36E4114B; Sat, 27 May 2023 00:35:47 +0200 (CEST) Received: from mail-il1-f171.google.com (mail-il1-f171.google.com [209.85.166.171]) by mails.dpdk.org (Postfix) with ESMTP id 6A0E0406A2; Sat, 27 May 2023 00:35:45 +0200 (CEST) Received: by mail-il1-f171.google.com with SMTP id e9e14a558f8ab-33af5ed2636so7143035ab.2; Fri, 26 May 2023 15:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685140545; x=1687732545; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yJpzztm/Pfk8cal990J0H6i0ZRP4Ymhi9BIDG7CyLIA=; b=BKuO3EUsGgExg8yOwqJi+rJQObP3E3cBtvrRV2wh7M9Zi0u7AzPupCLduoDPMzvFSB JRqEck8uKp6Yg2Z7/V1iTY1DLVDzpsEtG+bqg802WO3TR92xhG7Ilbw3oIQSckDknKps tsmHTpSNVrA4HW0d8tPEIhiD+nhjq84SHkduJB/z629AVS4MVzbH8htzCiotkgH6HOSB cknj+Ienl0WRyrcPYEFMsmUhI8H+azfP8IhQsIUZtoK76J5F/Na30C6s/BBZkoUjSQsy /UOJZ7WOblN9Z+VIGrXO84BAkWZ4zR2ze8/iVlov9a3jKnSvoW6FWRox3ErQXADZbk+v kZUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685140545; x=1687732545; 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=yJpzztm/Pfk8cal990J0H6i0ZRP4Ymhi9BIDG7CyLIA=; b=VdwiVgJCmKxPk13vcxasZFW3YF/HlCPHrZN1mCUFbbTVTA72DqjZaeGFySZhgpl8wB ipXs/BmmImoPzkZSRHSrfpgWD+xTvLBAJGC5OZFmktoumcRCqosL2r5AuWlLX6IZ6upm BLhtMuT+qqm8CipVmsz/6oaSfjk1Y0nIjtCEcHu1OLZxI4eUXX50cVhptjqSjKT2nd4i 1zAlQ3LXB0iKmMdI1cNUjZIslTZybIptZ38dSSIQB6ER9b50hePJl+8HHlTyKmk0QHhK O6NdK5lHD+oDQTkZ/wpQzMb1PKdryeaMzkZvJwKSKzez+KykOCt/0PVQen3fSM+LvZNI mfVQ== X-Gm-Message-State: AC+VfDz3bKV2R3wzWx5YbgaZMCoztWT/DgWpNPG2DZuQgJzawu0yJMSN auez1Ic6lM18p1NGkdPr4AWXVjZGkRwZaGLUuo8= X-Google-Smtp-Source: ACHHUZ5ru4pPK1/A5lNjDyQSs/qocLUNR/Dzt+3CYbsL7LwGLJO18BH33zcnvM4wns7sCOz0sEHoG29MgOYzVF7VX6o= X-Received: by 2002:a92:d2cd:0:b0:33b:66b:5003 with SMTP id w13-20020a92d2cd000000b0033b066b5003mr654580ilg.31.1685140544690; Fri, 26 May 2023 15:35:44 -0700 (PDT) MIME-Version: 1.0 References: <20230428170446.122c8775@hermes.local> <16663033.Ash8RoxBsO@thomas> In-Reply-To: From: Cliff Burdick Date: Fri, 26 May 2023 15:35:32 -0700 Message-ID: Subject: Re: Generic flow string parser To: Thomas Monjalon Cc: Tom Barbette , Stephen Hemminger , David Marchand , users , Ori Kam , dev@dpdk.org Content-Type: multipart/alternative; boundary="0000000000009021db05fca05ba4" 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 --0000000000009021db05fca05ba4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 29, 2023 at 2:49=E2=80=AFPM Cliff Burdick = wrote: > > 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 flo= w, > > meaning it calls rte_flow_create() under the hood. > > Is it what you wish? > > Or should it fill port ID, attributes, patterns and actions? > > > > I think it should follow closely with what "flow_parse" already does: > https://github.com/DPDK/dpdk/blob/d03446724972d2a1bb645ce7f3e64f5ef0203d6= 1/app/test-pmd/cmdline_flow.c#L11304 > > > > Namely, just do the part of populating attributes, patterns, and action= s > from a string. It's then up to the user if they want to create, validate, > or do something else with it (like see how it populate> d the structures)= . > The flow_parse function appears to take an opaque pointer that's specific > to a structure inside of cmdline_flow.c and assign the attributes, action= s, > and patterns to members of that result struct. I don't know the reason fo= r > this, but when >calling the function the user doesn't know how many > patterns or actions their string will generate. They would either need to > pass in structures that are allocated larger than needed, or have a > separate API that returns how many actions and patterns are needed for a > string, then they need to allocate the correct size themselves. I'm > assuming it's not ideal to have the library itself do dynamic memory > allocations for the correct size. > >> >> Tom, for what it's worth I'm on a quest to get this to work since I thin= k it's necessary. I'm just hacking through it like you did and I ran into the same "template" keyword error. It's probably worthwhile to fix that anyways. I'm maintaining a set of patches as I go. The general strategy has been to remove testpmd's main function, compile it as a library, and link against that. --0000000000009021db05fca05ba4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Apr 29, 2023 at 2:49=E2=80=AF= PM Cliff Burdick <shaklee3@gmail.c= om> wrote:
> So the only things we need are 2 functions, if I un= derstand 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 w= hat you wish?
> Or should it fill port ID, attributes, patterns and a= ctions?
>
> I think it should follow closely with w= hat "flow_parse" already does:=C2=A0https://github.com/DPDK/dpdk/blob/d0344= 6724972d2a1bb645ce7f3e64f5ef0203d61/app/test-pmd/cmdline_flow.c#L11304<= /div>
>=C2=A0
> Namely, just do the part of populating = attributes, patterns, and actions from a string. It's then up to the us= er if they want to create, validate, or do something else with it (like see= how it populate> d the structures). The flow_parse function appears to = take an opaque pointer that's specific to a structure inside of cmdline= _flow.c and assign the attributes, actions, and patterns to members of that= result struct. I don't know the reason for this, but when >calling = the function the user doesn't know how many patterns or actions their s= tring will generate. They would either need to pass in structures that are = allocated larger than needed, or have a separate API that returns how many = actions and patterns are needed for a string, then they need to allocate th= e correct size themselves. I'm assuming it's not ideal to have the = library itself do dynamic memory allocations for the correct size.

Tom, for what it's worth = I'm on a quest to get this to work since I think it's necessary. I&= #39;m just hacking through it like you did and I ran into the same "te= mplate" keyword error. It's probably worthwhile to fix that anyway= s. I'm maintaining a set of patches as I go. The general strategy has b= een to remove testpmd's=C2=A0main function, compile it as a library, an= d link against that.
--0000000000009021db05fca05ba4--