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

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
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).

Thanks,
Pablo

  reply	other threads:[~2014-06-27 15:47 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 [this message]
2014-06-27 16:26     ` Neil Horman

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=E115CCD9D858EF4F90C690B0DCB4D8971A79140D@IRSMSX103.ger.corp.intel.com \
    --to=pablo.de.lara.guarch@intel.com \
    --cc=dev@dpdk.org \
    --cc=nhorman@tuxdriver.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).