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

[Wisam Monther]

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk at gmail.com>
> Sent: Friday, March 20, 2020 2:18 PM
> To: Thomas Monjalon <thomas at monjalon.net>
> Cc: Wisam Monther <wisamm at mellanox.com>; dpdk-dev <dev at dpdk.org>;
> Matan Azrad <matan at mellanox.com>; Raslan Darawsheh
> <rasland at 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 <thomas at monjalon.net>
> wrote:
> >
> > 20/03/2020 07:49, Jerin Jacob:
> > > On Tue, Mar 17, 2020 at 7:16 PM Wisam Jaddo <wisamm at 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,
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

> >
> > > > The app supports single and multi core performance measurements.
> >
> >
> >