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.
