From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <xms:Vpz0Y0vz06k4rpgZQ8t-Z9ax0bbI2SklEDEEuYkljzMjhzpBNiO6Xg>
 <xme:Vpz0YxcV7lYSU_6YjO72JAUMFha3P9IjD_V6whpO7K3zbwxSXRNzEMA148ijXfXEr
 spyC1WlAu443zSR6g>
X-ME-Received: <xmr:Vpz0Y_z85UQrsPo-NDz1YmlUV4MuWhFmmRomfB-q_UCyv_ppMriA9ERkWfGLtc3ytN0pn2iTjnzzotWut2dX-rcq3A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudejjedgudehucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
 cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm
 rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc
 ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei
 kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh
 hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght
X-ME-Proxy: <xmx:Vpz0Y3OLavz6NuWcxqU1m0Yqdmx4aUqjMYiaa-jc_eAFltqDSX6tgw>
 <xmx:Vpz0Y0927rYoiB2iiaeGyhY1xHESpBrU7cWp4v5YMK4LMfl_5JOHHw>
 <xmx:Vpz0Y_X1jTWJw8RNkWnikLkomv0j1Z9dFgHJr3b7ClswOd65BBfwBg>
 <xmx:V5z0Y4UGNn5cYV1sgyot8WaHLFT8XZnGIZ52QuShRkXg45f_iqekRg>
Feedback-ID: i47234305:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue,
 21 Feb 2023 05:26:28 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: Eli Britstein <elibr@nvidia.com>,
 "Singh, Aman Deep" <aman.deep.singh@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Slava Ovsiienko <viacheslavo@nvidia.com>,
 Ori Kam <orika@nvidia.com>, Matan Azrad <matan@nvidia.com>,
 Gaetan Rivet <gaetanr@nvidia.com>, Nir Anteby <nanteby@nvidia.com>,
 Yuying Zhang <yuying.zhang@intel.com>,
 Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
 Asaf Penso <asafp@nvidia.com>, ferruh.yigit@amd.com,
 david.marchand@redhat.com, jerinj@marvell.com, ajit.khaparde@broadcom.com,
 Ivan Malov <ivan.malov@arknetworks.am>
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: <DM5PR1201MB2555A33CB3FDC9290FE3C707CDD39@DM5PR1201MB2555.namprd12.prod.outlook.com>
References: <20220704082433.3698761-1-elibr@nvidia.com>
 <DM6PR12MB481124A635574E9C225B54E8D8609@DM6PR12MB4811.namprd12.prod.outlook.com>
 <DM5PR1201MB2555A33CB3FDC9290FE3C707CDD39@DM5PR1201MB2555.namprd12.prod.outlook.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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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 <elibr@nvidia.com>
> >Sent: Sunday, 7 August 2022 10:01
> >To: Singh, Aman Deep <aman.deep.singh@intel.com>; dev@dpdk.org
> >Cc: Slava Ovsiienko <viacheslavo@nvidia.com>; Ori Kam <orika@nvidia.com>;
> >Asaf Penso <asafp@nvidia.com>; Matan Azrad <matan@nvidia.com>; Gaetan
> >Rivet <gaetanr@nvidia.com>; Nir Anteby <nanteby@nvidia.com>; Yuying
> >Zhang <yuying.zhang@intel.com>; Ferruh Yigit <ferruh.yigit@xilinx.com>;
> >Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>; NBU-Contact-
> >Thomas Monjalon (EXTERNAL) <thomas@monjalon.net>
> >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 <aman.deep.singh@intel.com>
> >>Sent: Thursday, July 28, 2022 5:07 PM
> >>To: dev@dpdk.org; Eli Britstein <elibr@nvidia.com>
> >>Cc: Slava Ovsiienko <viacheslavo@nvidia.com>; Ori Kam
> >><orika@nvidia.com>; Asaf Penso <asafp@nvidia.com>; Matan Azrad
> >><matan@nvidia.com>; Gaetan Rivet <gaetanr@nvidia.com>; Nir Anteby
> >><nanteby@nvidia.com>; Yuying Zhang <yuying.zhang@intel.com>; Ferruh
> >>Yigit <ferruh.yigit@xilinx.com>; Andrew Rybchenko
> >><andrew.rybchenko@oktetlabs.ru>; NBU-Contact- Thomas Monjalon
> >>(EXTERNAL) <thomas@monjalon.net>
> >>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.