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