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

[Jerin Jacob <jerinjacobk@gmail.com>]

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