Re: [dpdk-dev] [RFC] app/test-regex: add RegEx test application.

[Ori Kam <orika@mellanox.com>]

Hi Jerin

> -----Original Message-----
> From: Jerin Jacob <jerinjacobk@gmail.com>
> Sent: Thursday, June 4, 2020 9:31 AM
> Subject: Re: [dpdk-dev] [RFC] app/test-regex: add RegEx test application.
> 
> On Thu, Jun 4, 2020 at 11:21 AM Ori Kam <orika@mellanox.com> wrote:
> >
> > Hi Jerin,
> 
> HI Ori,
> 
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjacobk@gmail.com>
> > > Sent: Thursday, June 4, 2020 7:56 AM
> > > Subject: Re: [dpdk-dev] [RFC] app/test-regex: add RegEx test application.
> > >
> > > On Thu, Jun 4, 2020 at 2:59 AM Ori Kam <orika@mellanox.com> wrote:
> > > >
> > > > Following the new RegEx class [1].
> > > > There is a need to create a dedecated test application in order to
> > > > validate this class and PMD.
> > > >
> > > > Unlike net device this application loads data from a file.
> > > >
> > > > This commit introduce the new RegEx test app.
> > > >
> > > > The basic app flow:
> > > > 1. query probed RegEx device.
> > > > 2. configure the probed device accoding to the device caps.
> > > > 3. read a rule database file.
> > > > 4. read a data file to be searched.
> > > > 5. allocate one mbuf.
> > > > 6. select the request job len, based on the number of jobs requsted.
> > > > 7. create one RegEx op which uses the mbuf defined in step 5.
> > > > 8. attach the data buffer at offset 0 with len accoding to request
> > > >    len to the mbuf as external buffer.
> > > > 9. enqueue one job.
> > > > 10. wait for completion of the job.
> > > > 11. check job results and print them.
> > > > 12. move the mbuf to point to the next part of the buffer.
> > > > 13. while there are more parts jump to 9.
> > > >
> > > > Future improvments to this application may include:
> > > > 1. submiting more then one job at a time.
> > > > 2. working with more then one queue.
> > > > 3. support out of order.
> > > > 4. allow runtime rule updating.
> > > >
> > > > This commit is only at RFC level, which means that
> > > > the code is only basic reference and can't be compiled and doesn't
> > > > include error or edge case handling.
> > > >
> > > >
> > >
> [1]https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatche
> > >
> s.dpdk.org%2Fcover%2F69919%2F&amp;data=02%7C01%7Corika%40mellanox.
> > >
> com%7C777869b8df174845154008d80843aa33%7Ca652971c7d2e4d9ba6a4d1
> > >
> 49256f461b%7C0%7C0%7C637268433993878386&amp;sdata=GzSEh6O0rqPHBl
> > > OtkTGx3j6VGOdVykga2zYsuyK%2BxtM%3D&amp;reserved=0
> > > >
> > > > Signed-off-by: Ori Kam <orika@mellanox.com>
> > >
> > > IMO, this kind simile application with fixed-function can go in the
> > > example folder.
> > > I think, for app/test-regex, it better to have a framework to add new
> > > tests, modes, parse the modes, etc.
> > > Please see git log app/test-eventdev/ initial check-ins for the
> > > skeleton as a reference
> >
> > Currently all dedicateded tests for example, the crypto are located in this
> folder.
> > As I see it the example folder is used for simple programs to be used as a
> reference, while this app should be used to test the
> > RegEx class, I assume it will get much more functionality to support all test
> modes.
> 
> Yes. We are on the same, What I meant is to create  a framework for
> adding testcase and options
> first before addingthe test so that it can scale.
> see as just reference
> app/test-eventdev/evt_test.h
> app/test-eventdev/evt_options.h
> 
> 
I guess some of the new features will be in different files, while others will be just command
line option. The beauty  is that we don't need to decide everything now, and the desition will be based 
on the scale of the feature.

> 
> >
> > Best,
> > Ori
> >
> >