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 AF2A841CFC; Tue, 21 Feb 2023 11:26:35 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9191E431B0; Tue, 21 Feb 2023 11:26:35 +0100 (CET) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id A6707406A2 for ; Tue, 21 Feb 2023 11:26:33 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 5013E5C00F0; Tue, 21 Feb 2023 05:26:31 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 21 Feb 2023 05:26:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding: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=fm1; t=1676975191; x= 1677061591; bh=jxK0KF7lzjNKeVoWaMpuxsDo7LOFjNTnuZnSLgrq0ck=; b=X EoLJ105ORosHHlpRh84NTh6ikL3MXTPISx/g49zJ2yk+PVrvW4n0OcBfkwsPQNbv 2T+Jbqmg+z4hzrerd+qJNPHC/K2xqLA1sB8l32p3DnRZaaOlSgQHizCb4Pj4qZ4M qkGcB8yfrNIyepFI2twmjdR04o1VbsftH8yU7iHuojAdFQr+702VHURJTdeaJHOP dPIkEpgX27deqtVZALkOE8xhVE4Lr+ahRH63ECneu8Hp3BsGelXOee4GrF5JVayj 2uQ729xVyoHhm2Smk3FlVNi3xGJd+5dhAE3wU/5u0HLd+r4c5AC7ASx1Zunp8M0l xMJK3bzn/rpYT7buCCH5A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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=fm1; t=1676975191; x= 1677061591; bh=jxK0KF7lzjNKeVoWaMpuxsDo7LOFjNTnuZnSLgrq0ck=; b=H IawHPXoU1wH9zvn0wMUVC6tJs9oWhgnYZ+EipuM1Me41L2n88SFB4r6B7PlvdWU+ sUT81Z1mP5cHWZOr39vI3iIXorf5+4v6RoVuA81UK68SFTPMBpCtoNWqVHhJvqGO ORyMYe7mNEjPcDzkk2Q1fcfKXJSiy42xOzmdlXolVDxYe3UymsYtPQxpyZw/YE/1 pHmEeAoqh+XU58nCbUh+jZXnaBuCFS1heqAC0uS5QlsfkISlyImhd8HCC6Adod6I wJPg51hc6aJVpmqBmhAStYlBCAQqj7JbqbTvvGcVuk5lu/0vlNsYY6UPl3Vge0i7 UC1xtXEPx9xFrKReVEnbQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudejjedgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 21 Feb 2023 05:26:28 -0500 (EST) From: Thomas Monjalon To: Eli Britstein , "Singh, Aman Deep" Cc: "dev@dpdk.org" , Slava Ovsiienko , Ori Kam , Matan Azrad , Gaetan Rivet , Nir Anteby , Yuying Zhang , Andrew Rybchenko , Asaf Penso , ferruh.yigit@amd.com, david.marchand@redhat.com, jerinj@marvell.com, ajit.khaparde@broadcom.com, Ivan Malov Subject: Re: [dpdk-dev] [RFC] testpmd: support user-id attribute Date: Tue, 21 Feb 2023 11:26:26 +0100 Message-ID: <2087714.otsE0voPBg@thomas> In-Reply-To: References: <20220704082433.3698761-1-elibr@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 feature assigns custom IDs to flow rules so a complete sequence of commands can prepared in a script. As a test application, I think it is really valuable to be able to script a sequence. Any other opinions? If you want to see this feature please speak to encourage its development. 30/01/2023 11:03, Asaf Penso: > Hello Aman, > Can you clarify your intention? Like Eli mentioned, the group_id is less relevant for that purpose. Even with the same group_id we wish to have several different flows with different user-id. > > All, > Do you have any other comments? > We would like to proceed with the process of sending v1, review, and integrate. > > Regards, > Asaf Penso > > >-----Original Message----- > >From: Eli Britstein > >Sent: Sunday, 7 August 2022 10:01 > >To: Singh, Aman Deep ; dev@dpdk.org > >Cc: Slava Ovsiienko ; Ori Kam ; > >Asaf Penso ; Matan Azrad ; Gaetan > >Rivet ; Nir Anteby ; Yuying > >Zhang ; Ferruh Yigit ; > >Andrew Rybchenko ; NBU-Contact- > >Thomas Monjalon (EXTERNAL) > >Subject: RE: [dpdk-dev] [RFC] testpmd: support user-id attribute > > > >Hi Aman, > > > >No, the group attribute has its own meaning, so it cannot be used for this > >purpose, unless I misunderstood your meaning. > > > >Thanks, > >Eli > > > >>-----Original Message----- > >>From: Singh, Aman Deep > >>Sent: Thursday, July 28, 2022 5:07 PM > >>To: dev@dpdk.org; Eli Britstein > >>Cc: Slava Ovsiienko ; Ori Kam > >>; Asaf Penso ; Matan Azrad > >>; Gaetan Rivet ; Nir Anteby > >>; Yuying Zhang ; Ferruh > >>Yigit ; Andrew Rybchenko > >>; NBU-Contact- Thomas Monjalon > >>(EXTERNAL) > >>Subject: Re: [dpdk-dev] [RFC] testpmd: support user-id attribute > >> > >>External email: Use caution opening links or attachments > >> > >> > >>Hi Eli, > >> > >>In RTE flow there is support for group_id attribute(u32). > >>Similar to the example you gave- > >> > >>testpmd> flow create 0 group 0x1234 ingress pattern eth / end actions > >>count / drop / end > >> > >>Please check if it fits the requirement. > >> > >>Regards > >>Aman > >> > >> > >>On 7/20/2022 2:14 AM, Thomas Monjalon wrote: > >>> +Cc ethdev and testpmd maintainers > >>> > >>> Any feedback about this need and solution? > >>> > >>> > >>> 04/07/2022 10:24, Eli Britstein: > >>>> Upon creation of a flow, testpmd assigns it a flow ID. Later, the > >>>> flow ID is used for flow operations (query, destroy, dump). > >>>> > >>>> The testpmd application allows to manage flow rules with its IDs. > >>>> The flow ID is known only when the flow is created. > >>>> In order to prepare a complete sequence of testpmd commands to > >>>> copy/paste, the flow IDs must be predictable. > >>>> > >>>> The idea brought here is to allow providing some user-defined ID, > >>>> chosen in advance of the effective flow creation. > >>>> > >>>> > >>>> Example: > >>>> > >>>> testpmd> flow create 0 ingress user_id 0x1234 pattern eth / end > >>>> testpmd> actions > >>>> count / drop / end > >>>> Flow rule #0 created, user-id 0x1234 > >>>> > >>>> testpmd> flow destroy 0 user_id rule 0x1234 > >>>> Flow rule #0 destroyed, user-id 0x1234 Here, "user_id" is a flag > >>>> that signifies the "rule" ID is the user-id. > >>>> > >>>> The motivation is from OVS. OVS dumps its "rte_flow_create" calls to > >>>> the log in testpmd commands syntax. As the flow ID testpmd would > >>>> assign is unkwon, it cannot log valid "flow destroy" commands. > >>>> > >>>> With the enhancement described above, valid testpmd commands can be > >>>> created in a log to copy/paste to testpmd. > >>>> The application's flows sequence can then be played back in testpmd, > >>>> to enable enhanced dpdk debug capabilities of the applications's > >>>> flows in a controlled environment of testpmd rather than a dynamic, > >>>> more difficult to debug environment of the application.