[dpdk-dev] [PATCH] test: Ring PMD unit test rollback

Neil Horman nhorman at tuxdriver.com
Fri Jun 27 18:26:47 CEST 2014


On Fri, Jun 27, 2014 at 03:47:07PM +0000, De Lara Guarch, Pablo wrote:
> Hi Neil,
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman
> > Sent: Friday, June 27, 2014 4:03 PM
> > To: De Lara Guarch, Pablo
> > Cc: dev at dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH] test: Ring PMD unit test rollback
> > 
> > On Fri, Jun 27, 2014 at 03:46:39PM +0100, Pablo de Lara wrote:
> > > From: Pablo de Lara <pablo.de.lara.guarch at intel.com>
> > >
> > > New ring PMD unit test requires extra EAL option (vdev),
> > > in order to pass, which I believe is incorrect, as this
> > > test should be focused on testing the API, without needing
> > > to pass any argument.
> > >
> > > Added again all functions that create all the ring devices
> > > necessary for the test, and remove the last two tests
> > > (test_pmd_ring_pair_create and test_pmd_ring_pair_attach),
> > > as they call functions that are deprecated.
> > >
> > > Signed-off-by: Pablo de Lara <pablo.de.lara.guarch at intel.com>
> > 
> > Nak, this also re-adds the need to link the pmd to the application, either
> > statically or at runtime (i.e. this implicitly obviates the -d option in
> > rte_eal_parse_args).  If you really want to re-add these api calls, I
> > recommend
> > that you split them into a separate ring library and ring_pmd library.
> > 
> > Neil
> > 
> > P.S. you did remember to use the -d option in your testing, right?  Without it
> > the pmd won't load and the vdev option won't find the proper pmd to parse
> > it.
> > 
> 
> Why does it need the -d? I could use the vdev option without loading any dynamic pmds, and
You don't need it only if you build the application statically.  If you build it
as shared objects you need to specify which pmds to load at run time using the
-d option.  If you're building statically then no, you don't need it.

> it created the devices, but it is just difficult to run a simple unit test, by having to know which
> ethdevs you have to create, instead of letting the test itself to create the ones that it needs,
> if you know what I mean. So, if this solution is not good enough, another idea could be to let 
> the unit test make calls to the application, creating the virtual devices needed. What I don't 
> like is the idea of having to pass the vdev to the generic test application, as it is intended to 
> run other tests and not just the ring pmd (we could do something like in the eal_flags test,
> where several test app instances are run, with different parameters, although I am not sure,
> if this is possible for this kind of test).
> 


Alternatively to restoring the API, you can hardcode the command line strings
into the test pmd, so you don't have to specify them at run time, and just pass
them directly to rte_eal_init.

The problem with just blindly adding back the API is that it requires any
application that might want to use the ring pmd to load it at run time
unilaterally.

Regards
Neil

> Thanks,
> Pablo
> 


More information about the dev mailing list