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

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

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

-- 
2.26.2.1730.g385c171

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

[Thomas Monjalon]

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

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

[Singh, Aman Deep]

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

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

[Eli Britstein]

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

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

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

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

[Thomas Monjalon]

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.

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

[Singh, Aman Deep]

As per RFC, I guess possible testpmd implementation will have a mapping between
user-id(new) <=> rule-id (old/testpmd)
And this mapping will be maintained in testpmd code.
Please check, if that is how it is planned?

Another option I feel that this mapping done outside, by intermediate script
OVS_log (with user id) => script => testpmd flow commands

Any other options/comments are welcome.

Thanks
Aman

On 2/21/2023 3:56 PM, Thomas Monjalon wrote:
> 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.
>
>
>
>