DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH] test: Ring PMD unit test rollback
Date: Fri, 27 Jun 2014 12:26:47 -0400
Message-ID: <20140627162647.GC9138@hmsreliant.think-freely.org> (raw)
In-Reply-To: <E115CCD9D858EF4F90C690B0DCB4D8971A79140D@IRSMSX103.ger.corp.intel.com>

On Fri, Jun 27, 2014 at 03:47:07PM +0000, De Lara Guarch, Pablo wrote:
> Hi Neil,
> 
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman
> > Sent: Friday, June 27, 2014 4:03 PM
> > To: De Lara Guarch, Pablo
> > Cc: dev@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@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@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
> 

      reply	other threads:[~2014-06-27 16:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-27 14:46 Pablo de Lara
2014-06-27 15:03 ` Neil Horman
2014-06-27 15:47   ` De Lara Guarch, Pablo
2014-06-27 16:26     ` Neil Horman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140627162647.GC9138@hmsreliant.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=pablo.de.lara.guarch@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git