Re: [dpdk-dev] [RFC] app/test-flow-perf: add rte_flow perf app

[Thomas Monjalon <thomas@monjalon.net>]

23/03/2020 12:41, Wisam Monther:
> From: Jerin Jacob <jerinjacobk@gmail.com>
> > On Mon, Mar 23, 2020 at 3:23 PM Wisam Monther wrote:
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > > On Fri, Mar 20, 2020 at 5:21 PM Thomas Monjalon wrote:
> > > > > 20/03/2020 07:49, Jerin Jacob:
> > > > > > On Tue, Mar 17, 2020 at 7:16 PM Wisam Jaddo 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

In general I prefer things disabled by default.
Option --test-fwd makes more sense and can accept some forwarding options.


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

Please make flows count a variable which can be changed with option.


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

Great, thanks