On Mon, Mar 23, 2020 at 3:23 PM Wisam Monther <wis...@mellanox.com> wrote: > > > > > -----Original Message----- > > From: Jerin Jacob <jerinjac...@gmail.com> > > Sent: Friday, March 20, 2020 2:18 PM > > To: Thomas Monjalon <tho...@monjalon.net> > > Cc: Wisam Monther <wis...@mellanox.com>; dpdk-dev <dev@dpdk.org>; > > Matan Azrad <ma...@mellanox.com>; Raslan Darawsheh > > <rasl...@mellanox.com> > > Subject: Re: [dpdk-dev] [RFC] app/test-flow-perf: add rte_flow perf app > > > > On Fri, Mar 20, 2020 at 5:21 PM Thomas Monjalon <tho...@monjalon.net> > > wrote: > > > > > > 20/03/2020 07:49, Jerin Jacob: > > > > On Tue, Mar 17, 2020 at 7:16 PM Wisam Jaddo <wis...@mellanox.com> > > wrote: > > > > > > > > Thanks for this application. Useful stuff. > > > > > > > > > > > > > > > > > Introducing new application for rte_flow performance testing. The > > > > > application provide the ability to test insertion rate of specific > > > > > rte_flow rule, by stressing it to the NIC, and calculate the > > > > > insertion rate. > > > > > > > > > > It also provides packet per second measurements after the > > > > > insertion operation is done. > > > > > > > > > > The application offers some options in the command line, to > > > > > configure which rule to apply. > > > > > > > > > > After that the application will start producing rules with same > > > > > pattern but increasing the outer IP source address by 1 each time, > > > > > thus it will give different flow each time, and all other items > > > > > will have open masks. > > > > > > > > > > The current design have single core insertion rate. > > > > > In the future we may have a multi core insertion rate measurement > > > > > support in the app. > > > > > > > > If I understand correctly, > > > > # On the main thread, this application first check the flow > > > > insertion performance # and then start the worker thread for packet > > > > forwarding. > > > > Why this application testing the packet forwarding?, We already have > > > > testpmd for that. > > > > > > I think it is interesting to measure forwarding performance when > > > million of flow rules are in effect. > > > > The rules are applied to the HW CAM, Right? > > Do you see any performance difference? > > > > Yes, there are applied to HW,
OK.IMO, it is better to introduce the command-line argument to disable/enable packet forwarding. That will enable if someone needs to test only flow insertion performance to avoid the IO setup. > > No not really, I still didn't test the impact of performance yet. > Moreover it's interesting to see such results and the impact on performance, > Also to see the rules are still matching after all Millions of insertion and > millions of packets > Sending/receiving. > > > > > > > > > IMO, This application needs to focus only on > > > > - Insertion performance > > > > - Deletion performance > > > > - IMO, it is better to add a framework for the profile where the > > > > first version of this application can define common a set of ITEMS > > > > and set of ACTION and later others can extend it. > > > > And the framework can run over all the profiles and spit out the > > > > insertion and deletion performance. > > > > > > What do you call a profile? Is it a set of rules? > > > > set of rules and/or actions. > > > > > I think this first version is proposing rules customization with > > > parameters. > > > > Just that it better to have a framework where one can easily add new > > profiles and test various combos. IMO, Cascade rules take more insertion > > time. > > > > > Note: I prefer a non-interactive application for performance testing. > > > > Me too. Command-line is fine. > > > > For this version I'm aiming to have the command line options to decide the > profile. > For example: > . /flow-perf -n 4 -w 0000:03:00.1,dv_flow_en=1 -- --ingress --ether --ipv4 > --udp --vxlan-gpe --queue --mark > Will mean 4 Million rules of: > Flow create 0 ingress pattern eth / ipv4 src is <X> / udp / vxlan-gpe / end > actions mark id 1 / queue < QUEUE _ID> / end Ok. The syntax looks good. I think we can add a number of rules as well in command like instead of hardcoding to 4Millon. And what about the flow deletion performance case? > > > > > > > > > > The app supports single and multi core performance measurements. > > > > > > > > >
