[dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx test to driver

Bruce Richardson bruce.richardson at intel.com
Wed Dec 13 11:34:28 CET 2017


On Wed, Dec 13, 2017 at 10:19:51AM +0000, Van Haaren, Harry wrote:
> > -----Original Message-----
> > From: Pavan Nikhilesh [mailto:pbhagavatula at caviumnetworks.com]
> > Sent: Tuesday, December 12, 2017 7:27 PM
> > To: jerin.jacob at caviumnetworks.com; Richardson, Bruce
> > <bruce.richardson at intel.com>; Van Haaren, Harry
> > <harry.van.haaren at intel.com>; Eads, Gage <gage.eads at intel.com>;
> > hemant.agrawal at nxp.com; nipun.gupta at nxp.com; Ma, Liang J
> > <liang.j.ma at intel.com>
> > Cc: dev at dpdk.org; Pavan Nikhilesh <pbhagavatula at caviumnetworks.com>
> > Subject: [dpdk-dev] [PATCH 1/7] event/octeontx: move eventdev octeontx test
> > to driver
> > 
> > Move octeontx eventdev specific test (test_eventdev_octeontx.c) to
> > driver/event/octeontx.
> 
> <snip patch content>
> 
> Replying to 1st patch, as no cover letter;
> 
> Summary of patchset:
> - Move tests for a specific Eventdev PMD into the PMD dir: drivers/event/x/x_selftest.c
> - Enable self tests to run when passed the vdev arg "self-test=1"
> 
> 
> A few comments on this change;
> 
> 1) We should not lose the capability to run tests as part of the existing unit testing infrastructure. We should not fragment the testing tool - requiring multiple binaries to test a single component.
> 
> From discussion on #IRC, it seems reasonable to call  rte_eal_vdev_init()  with "self-test=1" from the test/test/ code, and then we can continue to use the existing test infrastructure despite that the actual tests are now part of each PMD.
> 
> 2) We should not copy/paste TEST_ASSERT macros into new test files. Abstracting the TEST_ASSERT and other macros out to a header file would solve this duplication.
> 
> 
> Specific comments will be sent as replies to the patches. Cheers, -Harry

What I gather from a cursory glance at this set is that the self tests
are designed to be triggered via devargs to the device driver, correct?
I'm not sure I like this approach, though I do agree with having the
tests inside the individual drivers.

What I think I would prefer to see is the self-tests being called via an
API rather than via devargs. I think we should add a
"rte_event_dev_self_test()" API to the eventdev library, and have that
then call into the driver-provided tests. This means that self-tests can
only be called by applications which are set up to allow the tests to be
called, e.g. the autotest binary, while also avoiding the issue of
having lots of driver specifics clutter up test binaries.

Regards,
/Bruce


More information about the dev mailing list