> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Monday, March 23, 2020 3:00 PM
> To: Jerin Jacob <jerinjac...@gmail.com>; Wisam Monther
> <wis...@mellanox.com>
> Cc: 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
>
> 23/03/2020 12:41, Wisam Monther:
> > From: Jerin Jacob <jerinjac...@gmail.com>
> > > On Mon, Mar 23, 2020 at 3:23 PM Wisam Monther wrote:
> > > > From: Jerin Jacob <jerinjac...@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.
sure
>
>
> > > > 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.
Sure
>
>
> > > 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
>
Thanks,
