RE: [dpdk-dev] [RFC] testpmd: support user-id attribute

[Asaf Penso <asafp@nvidia.com>]

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.
>>>
>>>
>>>
>>>