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 <el...@nvidia.com> > >Sent: Sunday, 7 August 2022 10:01 > >To: Singh, Aman Deep <aman.deep.si...@intel.com>; dev@dpdk.org > >Cc: Slava Ovsiienko <viachesl...@nvidia.com>; Ori Kam <or...@nvidia.com>; > >Asaf Penso <as...@nvidia.com>; Matan Azrad <ma...@nvidia.com>; Gaetan > >Rivet <gaet...@nvidia.com>; Nir Anteby <nant...@nvidia.com>; Yuying > >Zhang <yuying.zh...@intel.com>; Ferruh Yigit <ferruh.yi...@xilinx.com>; > >Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>; NBU-Contact- > >Thomas Monjalon (EXTERNAL) <tho...@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.si...@intel.com> > >>Sent: Thursday, July 28, 2022 5:07 PM > >>To: dev@dpdk.org; Eli Britstein <el...@nvidia.com> > >>Cc: Slava Ovsiienko <viachesl...@nvidia.com>; Ori Kam > >><or...@nvidia.com>; Asaf Penso <as...@nvidia.com>; Matan Azrad > >><ma...@nvidia.com>; Gaetan Rivet <gaet...@nvidia.com>; Nir Anteby > >><nant...@nvidia.com>; Yuying Zhang <yuying.zh...@intel.com>; Ferruh > >>Yigit <ferruh.yi...@xilinx.com>; Andrew Rybchenko > >><andrew.rybche...@oktetlabs.ru>; NBU-Contact- Thomas Monjalon > >>(EXTERNAL) <tho...@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.
