> -----Original Message----- > From: Jerin Jacob <jerinjac...@gmail.com> > Sent: Monday, March 23, 2020 1:16 PM > To: Wisam Monther <wis...@mellanox.com> > Cc: Thomas Monjalon <tho...@monjalon.net>; 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 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. >
Sure, we can have the forwarding enabled by default, and I'll add --disable-fwd To command line options, it looks reasonable to have it, I agree > > > > 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. > Sure we can have it also BTW, I'm planning to have a file under "user_paramters.h" This file for other specific fields such as: /** Flows count & iteration size **/ #define FLOWS_COUNT 4000000 #define ITERATION_SIZE 100000 /** Configuration **/ #define RXQs 4 #define TXQs 4 #define HAIRPIN_QUEUES 4 #define TOTAL_MBUF_NUM 32000 #define MBUF_SIZE 2048 #define MBUF_CACHE_SIZE 512 #define NR_RXD 256 #define NR_TXD 256 /** Items/Actions parameters **/ #define FLOW_TABLE 1 #define JUMP_ACTION_TABLE 2 #define VLAN_VALUE 1 #define VNI_VALUE 1 #define GRE_PROTO 0x6558 #define META_DATA 1 #define TAG_INDEX 0 #define PORT_ID_DST 1 #define MARK_ID 1 #define TEID_VALUE 1 > And what about the flow deletion performance case? I agree we should have it as well in this application, I plan it to do it as well > > > > > > > > > > > > > > > > The app supports single and multi core performance > measurements. > > > > > > > > > > > >
