From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <users-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id C904442BAD for <public@inbox.dpdk.org>; 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: <CA+Gp1na5XK1apYrsrG3KsDyZ3Y4oYyTV+2rN=iVrZct=kEKk-g@mail.gmail.com> <20230428170446.122c8775@hermes.local> <CA+Gp1naKMx3dFut3qYwnZNUOaTs9VqCCYrC9EkxjnUgBLenKUw@mail.gmail.com> <16663033.Ash8RoxBsO@thomas> <CA+Gp1naQPrWofrEohB9=35f7v1bBggaEO6A7p5u9-Q+LiQcELA@mail.gmail.com> In-Reply-To: <CA+Gp1naQPrWofrEohB9=35f7v1bBggaEO6A7p5u9-Q+LiQcELA@mail.gmail.com> From: Cliff Burdick <shaklee3@gmail.com> Date: Fri, 26 May 2023 15:35:32 -0700 Message-ID: <CA+Gp1nZc9UpwejtFvWA6U+Ko-YS7=fOXYn5LiKvqizCWgornqQ@mail.gmail.com> Subject: Re: Generic flow string parser To: Thomas Monjalon <thomas@monjalon.net> Cc: Tom Barbette <tom.barbette@uclouvain.be>, Stephen Hemminger <stephen@networkplumber.org>, David Marchand <david.marchand@redhat.com>, users <users@dpdk.org>, Ori Kam <orika@nvidia.com>, 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 <users.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/users>, <mailto:users-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/users/> List-Post: <mailto:users@dpdk.org> List-Help: <mailto:users-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/users>, <mailto:users-request@dpdk.org?subject=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 <shaklee3@gmail.com> = 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 <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Sat, Apr 29, 2023 at 2:49=E2=80=AF= PM Cliff Burdick <<a href=3D"mailto:shaklee3@gmail.com">shaklee3@gmail.c= om</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex= "><div dir=3D"ltr">> So the only things we need are 2 functions, if I un= derstand well:<br>><br>> int rte_flow_to_text(const struct rte_flow*)= ;<br>> struct rte_flow *rte_flow_from_text(const char *);<br>><br>>= ; Here I assume the output of rte_flow_from_text() would be a created flow,= <br>> meaning it calls rte_flow_create() under the hood.<br>> Is it w= hat you wish?<br>> Or should it fill port ID, attributes, patterns and a= ctions?<br><div>></div><div>> I think it should follow closely with w= hat "flow_parse" already does:=C2=A0<a href=3D"https://github.com= /DPDK/dpdk/blob/d03446724972d2a1bb645ce7f3e64f5ef0203d61/app/test-pmd/cmdli= ne_flow.c#L11304" target=3D"_blank">https://github.com/DPDK/dpdk/blob/d0344= 6724972d2a1bb645ce7f3e64f5ef0203d61/app/test-pmd/cmdline_flow.c#L11304</a><= /div><div>>=C2=A0</div><div>> 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.</div></d= iv><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma= rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:= 1ex"><br></blockquote></div></blockquote><div>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.</div></div></div> --0000000000009021db05fca05ba4--