[dpdk-dev] [PATCH 0/2] Enable fast-unit tests under travis

[dpdk-dev] [PATCH 0/2] Enable fast-unit tests under travis

[Aaron Conole]

This series turns the fast unit tests on for a limited set of
builds under the travis build system.  An example run is available
at:

https://travis-ci.org/orgcandman/dpdk/builds/565991679

The builds which execute the unit tests may be distinguished by the
"RUN_TESTS" parameter.

Aaron Conole (1):
  ci: enable unit tests under travis-ci

Michael Santana (1):
  tests: Fix unit tests for shared builds

 .ci/linux-build.sh   | 8 ++++++++
 .ci/linux-setup.sh   | 8 +++++++-
 .travis.yml          | 9 ++++++++-
 app/test/meson.build | 9 +++++++++
 4 files changed, 32 insertions(+), 2 deletions(-)

-- 
2.21.0

[dpdk-dev] [PATCH 1/2] tests: Fix unit tests for shared builds

[Aaron Conole]

From: Michael Santana <msantana@redhat.com>

Currently many unit tests fail when running tests under shared builds.
This happens because of missing driver dependencies. This is fixed by
explicitly linking in missing drivers for the test application.

before and after (clang):
https://travis-ci.com/Maickii/dpdk-2/jobs/212329160#L623
https://travis-ci.com/Maickii/dpdk-2/jobs/212335912#L620

Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
Suggested-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
Signed-off-by: Aaron Conole <aconole@redhat.com>
---
 app/test/meson.build | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/app/test/meson.build b/app/test/meson.build
index c50b20275..7bf700f29 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -297,6 +297,15 @@ dump_test_names = [
         'dump_memzone',
 ]
 
+if dpdk_conf.has('RTE_LIBRTE_RING_MEMPOOL')
+	test_deps += 'mempool_ring'
+endif
+if dpdk_conf.has('RTE_LIBRTE_STACK_MEMPOOL')
+	test_deps += 'mempool_stack'
+endif
+if dpdk_conf.has('RTE_LIBRTE_SKELETON_EVENTDEV_PMD')
+	test_deps += 'pmd_skeleton_event'
+endif
 if dpdk_conf.has('RTE_LIBRTE_PDUMP')
 	test_deps += 'pdump'
 endif
-- 
2.21.0

Re: [dpdk-dev] [PATCH 1/2] tests: Fix unit tests for shared builds

[Bruce Richardson]

On Wed, Jul 31, 2019 at 10:50:29AM -0400, Aaron Conole wrote:
> From: Michael Santana <msantana@redhat.com>
> 
> Currently many unit tests fail when running tests under shared builds.
> This happens because of missing driver dependencies. This is fixed by
> explicitly linking in missing drivers for the test application.
> 
> before and after (clang):
> https://travis-ci.com/Maickii/dpdk-2/jobs/212329160#L623
> https://travis-ci.com/Maickii/dpdk-2/jobs/212335912#L620
> 
> Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
> Suggested-by: David Marchand <david.marchand@redhat.com>
> Signed-off-by: Michael Santana <msantana@redhat.com>
> Signed-off-by: Aaron Conole <aconole@redhat.com>
> ---
Rather than linking in the libraries explicitly, can you have the build do
a "ninja install" at the end to place the libraries and drivers in their
correct paths. That should mean that the test app (via eal) auto-loads all
drivers from EAL_PMD_PATH (/usr/local/...). It would save having to make
further changes to this file to link in any additional drivers.

EAL_PMD_PATH is based off of $prefix for the build or install, so you can
adjust that using meson options, if putting the drivers in /usr/local is
not desirable for your test environments.

/Bruce

Re: [dpdk-dev] [PATCH 1/2] tests: Fix unit tests for shared builds

[Aaron Conole]

Bruce Richardson <bruce.richardson@intel.com> writes:

> On Wed, Jul 31, 2019 at 10:50:29AM -0400, Aaron Conole wrote:
>> From: Michael Santana <msantana@redhat.com>
>> 
>> Currently many unit tests fail when running tests under shared builds.
>> This happens because of missing driver dependencies. This is fixed by
>> explicitly linking in missing drivers for the test application.
>> 
>> before and after (clang):
>> https://travis-ci.com/Maickii/dpdk-2/jobs/212329160#L623
>> https://travis-ci.com/Maickii/dpdk-2/jobs/212335912#L620
>> 
>> Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
>> Suggested-by: David Marchand <david.marchand@redhat.com>
>> Signed-off-by: Michael Santana <msantana@redhat.com>
>> Signed-off-by: Aaron Conole <aconole@redhat.com>
>> ---
> Rather than linking in the libraries explicitly, can you have the build do
> a "ninja install" at the end to place the libraries and drivers in their
> correct paths. That should mean that the test app (via eal) auto-loads all
> drivers from EAL_PMD_PATH (/usr/local/...). It would save having to make
> further changes to this file to link in any additional drivers.
>
> EAL_PMD_PATH is based off of $prefix for the build or install, so you can
> adjust that using meson options, if putting the drivers in /usr/local is
> not desirable for your test environments.

The downside of not explicitly linking this way is that a developer
won't be able to do something like:

  meson build
  ninja -C build

  ... development work

  ninja -C build test

Rather, they will notice broken tests and not care about testing any
more (since that's what we're dealing with now).

Requiring that a developer do the install (ninja -C build install) then
presents a different problem: before doing the 'test' I *must* remember
to do the install.  Otherwise I won't be testing with the correct
version of the libraries.

Is there a way to adjust the library search path?  Maybe we can solve
this by making that search path adjusted during the unit tests to look
in all the various build directories?

> /Bruce

Re: [dpdk-dev] [PATCH 1/2] tests: Fix unit tests for shared builds

[Aaron Conole]

Aaron Conole <aconole@redhat.com> writes:

> Bruce Richardson <bruce.richardson@intel.com> writes:
>
>> On Wed, Jul 31, 2019 at 10:50:29AM -0400, Aaron Conole wrote:
>>> From: Michael Santana <msantana@redhat.com>
>>> 
>>> Currently many unit tests fail when running tests under shared builds.
>>> This happens because of missing driver dependencies. This is fixed by
>>> explicitly linking in missing drivers for the test application.
>>> 
>>> before and after (clang):
>>> https://travis-ci.com/Maickii/dpdk-2/jobs/212329160#L623
>>> https://travis-ci.com/Maickii/dpdk-2/jobs/212335912#L620
>>> 
>>> Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
>>> Suggested-by: David Marchand <david.marchand@redhat.com>
>>> Signed-off-by: Michael Santana <msantana@redhat.com>
>>> Signed-off-by: Aaron Conole <aconole@redhat.com>
>>> ---
>> Rather than linking in the libraries explicitly, can you have the build do
>> a "ninja install" at the end to place the libraries and drivers in their
>> correct paths. That should mean that the test app (via eal) auto-loads all
>> drivers from EAL_PMD_PATH (/usr/local/...). It would save having to make
>> further changes to this file to link in any additional drivers.

Oops, forgot to include a link to a build where I did this.  It's
failing (you can see the corresponding commit at
https://github.com/orgcandman/dpdk/commit/ccba975bdfe851b4c8ec3f208451bb105317b76d):

  https://travis-ci.org/orgcandman/dpdk/jobs/566044409

>> EAL_PMD_PATH is based off of $prefix for the build or install, so you can
>> adjust that using meson options, if putting the drivers in /usr/local is
>> not desirable for your test environments.
>
> The downside of not explicitly linking this way is that a developer
> won't be able to do something like:
>
>   meson build
>   ninja -C build
>
>   ... development work
>
>   ninja -C build test
>
> Rather, they will notice broken tests and not care about testing any
> more (since that's what we're dealing with now).
>
> Requiring that a developer do the install (ninja -C build install) then
> presents a different problem: before doing the 'test' I *must* remember
> to do the install.  Otherwise I won't be testing with the correct
> version of the libraries.
>
> Is there a way to adjust the library search path?  Maybe we can solve
> this by making that search path adjusted during the unit tests to look
> in all the various build directories?
>
>> /Bruce

Re: [dpdk-dev] [PATCH 1/2] tests: Fix unit tests for shared builds

[Bruce Richardson]

On Wed, Jul 31, 2019 at 12:10:55PM -0400, Aaron Conole wrote:
> Aaron Conole <aconole@redhat.com> writes:
> 
> > Bruce Richardson <bruce.richardson@intel.com> writes:
> >
> >> On Wed, Jul 31, 2019 at 10:50:29AM -0400, Aaron Conole wrote:
> >>> From: Michael Santana <msantana@redhat.com>
> >>> 
> >>> Currently many unit tests fail when running tests under shared builds.
> >>> This happens because of missing driver dependencies. This is fixed by
> >>> explicitly linking in missing drivers for the test application.
> >>> 
> >>> before and after (clang):
> >>> https://travis-ci.com/Maickii/dpdk-2/jobs/212329160#L623
> >>> https://travis-ci.com/Maickii/dpdk-2/jobs/212335912#L620
> >>> 
> >>> Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
> >>> Suggested-by: David Marchand <david.marchand@redhat.com>
> >>> Signed-off-by: Michael Santana <msantana@redhat.com>
> >>> Signed-off-by: Aaron Conole <aconole@redhat.com>
> >>> ---
> >> Rather than linking in the libraries explicitly, can you have the build do
> >> a "ninja install" at the end to place the libraries and drivers in their
> >> correct paths. That should mean that the test app (via eal) auto-loads all
> >> drivers from EAL_PMD_PATH (/usr/local/...). It would save having to make
> >> further changes to this file to link in any additional drivers.
> 
> Oops, forgot to include a link to a build where I did this.  It's
> failing (you can see the corresponding commit at
> https://github.com/orgcandman/dpdk/commit/ccba975bdfe851b4c8ec3f208451bb105317b76d):
> 
>   https://travis-ci.org/orgcandman/dpdk/jobs/566044409
> 
I think the error may be due to having some drivers already linked in while
trying to reload all drivers dynamically. The dynamic loading of drivers I
actually think we could make more robust. For example:

* only load .so files. If you pass in the drivers path from the build, it
  errors out trying to load .a files
* when loading directories, maybe skip any files which don't have a "librte"
  prefix - anyone who has their own drivers they want loaded can add the
  prefix or load it explicitly via -d
* alternatively, skip files which don't have a pmdinfo section in them
* allow skipping of drivers which are already linked in
* don't fail the whole process if one driver fails to load from a
  directory.

Regards,
/Bruce

Re: [dpdk-dev] [PATCH 1/2] tests: Fix unit tests for shared builds

[Aaron Conole]

Bruce Richardson <bruce.richardson@intel.com> writes:

> On Wed, Jul 31, 2019 at 12:10:55PM -0400, Aaron Conole wrote:
>> Aaron Conole <aconole@redhat.com> writes:
>> 
>> > Bruce Richardson <bruce.richardson@intel.com> writes:
>> >
>> >> On Wed, Jul 31, 2019 at 10:50:29AM -0400, Aaron Conole wrote:
>> >>> From: Michael Santana <msantana@redhat.com>
>> >>> 
>> >>> Currently many unit tests fail when running tests under shared builds.
>> >>> This happens because of missing driver dependencies. This is fixed by
>> >>> explicitly linking in missing drivers for the test application.
>> >>> 
>> >>> before and after (clang):
>> >>> https://travis-ci.com/Maickii/dpdk-2/jobs/212329160#L623
>> >>> https://travis-ci.com/Maickii/dpdk-2/jobs/212335912#L620
>> >>> 
>> >>> Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
>> >>> Suggested-by: David Marchand <david.marchand@redhat.com>
>> >>> Signed-off-by: Michael Santana <msantana@redhat.com>
>> >>> Signed-off-by: Aaron Conole <aconole@redhat.com>
>> >>> ---
>> >> Rather than linking in the libraries explicitly, can you have the build do
>> >> a "ninja install" at the end to place the libraries and drivers in their
>> >> correct paths. That should mean that the test app (via eal) auto-loads all
>> >> drivers from EAL_PMD_PATH (/usr/local/...). It would save having to make
>> >> further changes to this file to link in any additional drivers.
>> 
>> Oops, forgot to include a link to a build where I did this.  It's
>> failing (you can see the corresponding commit at
>> https://github.com/orgcandman/dpdk/commit/ccba975bdfe851b4c8ec3f208451bb105317b76d):
>> 
>>   https://travis-ci.org/orgcandman/dpdk/jobs/566044409
>> 
> I think the error may be due to having some drivers already linked in while
> trying to reload all drivers dynamically. The dynamic loading of drivers I
> actually think we could make more robust. For example:
>
> * only load .so files. If you pass in the drivers path from the build, it
>   errors out trying to load .a files
> * when loading directories, maybe skip any files which don't have a "librte"
>   prefix - anyone who has their own drivers they want loaded can add the
>   prefix or load it explicitly via -d
> * alternatively, skip files which don't have a pmdinfo section in them
> * allow skipping of drivers which are already linked in
> * don't fail the whole process if one driver fails to load from a
>   directory.

What change do you suggest I make to the steps I outlined?  I think it
seems to be more complex than a simple 'ninja install'.

Maybe it makes sense to merge these patches now and fix the library
loading code as a separate action?  Or is there a different procedure I
(and other developers) should follow?  Does it really need a 'ninja
install' even for a drive-by developer to make a small patch and test
before submitting?

> Regards,
> /Bruce

Re: [dpdk-dev] [PATCH 1/2] tests: Fix unit tests for shared builds

[Bruce Richardson]

On Thu, Aug 01, 2019 at 11:40:33AM -0400, Aaron Conole wrote:
> Bruce Richardson <bruce.richardson@intel.com> writes:
> 
> > On Wed, Jul 31, 2019 at 12:10:55PM -0400, Aaron Conole wrote:
> >> Aaron Conole <aconole@redhat.com> writes:
> >> 
> >> > Bruce Richardson <bruce.richardson@intel.com> writes:
> >> >
> >> >> On Wed, Jul 31, 2019 at 10:50:29AM -0400, Aaron Conole wrote:
> >> >>> From: Michael Santana <msantana@redhat.com>
> >> >>> 
> >> >>> Currently many unit tests fail when running tests under shared builds.
> >> >>> This happens because of missing driver dependencies. This is fixed by
> >> >>> explicitly linking in missing drivers for the test application.
> >> >>> 
> >> >>> before and after (clang):
> >> >>> https://travis-ci.com/Maickii/dpdk-2/jobs/212329160#L623
> >> >>> https://travis-ci.com/Maickii/dpdk-2/jobs/212335912#L620
> >> >>> 
> >> >>> Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
> >> >>> Suggested-by: David Marchand <david.marchand@redhat.com>
> >> >>> Signed-off-by: Michael Santana <msantana@redhat.com>
> >> >>> Signed-off-by: Aaron Conole <aconole@redhat.com>
> >> >>> ---
> >> >> Rather than linking in the libraries explicitly, can you have the build do
> >> >> a "ninja install" at the end to place the libraries and drivers in their
> >> >> correct paths. That should mean that the test app (via eal) auto-loads all
> >> >> drivers from EAL_PMD_PATH (/usr/local/...). It would save having to make
> >> >> further changes to this file to link in any additional drivers.
> >> 
> >> Oops, forgot to include a link to a build where I did this.  It's
> >> failing (you can see the corresponding commit at
> >> https://github.com/orgcandman/dpdk/commit/ccba975bdfe851b4c8ec3f208451bb105317b76d):
> >> 
> >>   https://travis-ci.org/orgcandman/dpdk/jobs/566044409
> >> 
> > I think the error may be due to having some drivers already linked in while
> > trying to reload all drivers dynamically. The dynamic loading of drivers I
> > actually think we could make more robust. For example:
> >
> > * only load .so files. If you pass in the drivers path from the build, it
> >   errors out trying to load .a files
> > * when loading directories, maybe skip any files which don't have a "librte"
> >   prefix - anyone who has their own drivers they want loaded can add the
> >   prefix or load it explicitly via -d
> > * alternatively, skip files which don't have a pmdinfo section in them
> > * allow skipping of drivers which are already linked in
> > * don't fail the whole process if one driver fails to load from a
> >   directory.
> 
> What change do you suggest I make to the steps I outlined?  I think it
> seems to be more complex than a simple 'ninja install'.
> 
> Maybe it makes sense to merge these patches now and fix the library
> loading code as a separate action?  Or is there a different procedure I
> (and other developers) should follow?  Does it really need a 'ninja
> install' even for a drive-by developer to make a small patch and test
> before submitting?
> 
I think your patch is the best solution for 19.08. Fixing the library
loading for developers is a larger job beyond that. 

Another item for future consideration: since meson/ninja automatically sets
the rpath for binaries in build directory - and then strips that out on
install - it would be really nice if we could leverage that somehow for
finding drivers.

/Bruce

Re: [dpdk-dev] [PATCH 1/2] tests: Fix unit tests for shared builds

[Bruce Richardson]

On Wed, Jul 31, 2019 at 10:50:29AM -0400, Aaron Conole wrote:
> From: Michael Santana <msantana@redhat.com>
> 
> Currently many unit tests fail when running tests under shared builds.
> This happens because of missing driver dependencies. This is fixed by
> explicitly linking in missing drivers for the test application.
> 
> before and after (clang):
> https://travis-ci.com/Maickii/dpdk-2/jobs/212329160#L623
> https://travis-ci.com/Maickii/dpdk-2/jobs/212335912#L620
> 
> Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
> Suggested-by: David Marchand <david.marchand@redhat.com>
> Signed-off-by: Michael Santana <msantana@redhat.com>
> Signed-off-by: Aaron Conole <aconole@redhat.com>
> ---
>  app/test/meson.build | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
Acked-by: Bruce Richardson <bruce.richardson@intel.com>

Re: [dpdk-dev] [PATCH 1/2] tests: Fix unit tests for shared builds

[Thomas Monjalon]

31/07/2019 16:50, Aaron Conole:
> From: Michael Santana <msantana@redhat.com>
> --- a/app/test/meson.build
> +++ b/app/test/meson.build
> +if dpdk_conf.has('RTE_LIBRTE_RING_MEMPOOL')
> +	test_deps += 'mempool_ring'
> +endif
> +if dpdk_conf.has('RTE_LIBRTE_STACK_MEMPOOL')
> +	test_deps += 'mempool_stack'
> +endif
> +if dpdk_conf.has('RTE_LIBRTE_SKELETON_EVENTDEV_PMD')
> +	test_deps += 'pmd_skeleton_event'
> +endif
>  if dpdk_conf.has('RTE_LIBRTE_PDUMP')
>  	test_deps += 'pdump'
>  endif

As these libraries are dynamically loadable as plugins,
it should be explained in comments that this explicit linking
is an exception to allow the developer run the unit tests
without intalling the libraries.
Otherwise, other applications will copy it.

Re: [dpdk-dev] [PATCH 1/2] tests: Fix unit tests for shared builds

[Aaron Conole]

Thomas Monjalon <thomas@monjalon.net> writes:

> 31/07/2019 16:50, Aaron Conole:
>> From: Michael Santana <msantana@redhat.com>
>> --- a/app/test/meson.build
>> +++ b/app/test/meson.build
>> +if dpdk_conf.has('RTE_LIBRTE_RING_MEMPOOL')
>> +	test_deps += 'mempool_ring'
>> +endif
>> +if dpdk_conf.has('RTE_LIBRTE_STACK_MEMPOOL')
>> +	test_deps += 'mempool_stack'
>> +endif
>> +if dpdk_conf.has('RTE_LIBRTE_SKELETON_EVENTDEV_PMD')
>> +	test_deps += 'pmd_skeleton_event'
>> +endif
>>  if dpdk_conf.has('RTE_LIBRTE_PDUMP')
>>  	test_deps += 'pdump'
>>  endif
>
> As these libraries are dynamically loadable as plugins,
> it should be explained in comments that this explicit linking
> is an exception to allow the developer run the unit tests
> without intalling the libraries.
> Otherwise, other applications will copy it.

Okay.  I'll add it.

[dpdk-dev] [PATCH 2/2] ci: enable unit tests under travis-ci

[Aaron Conole]

When building under Travis (or another linux CI service), enable running the
fast-tests for selected builds.  Only the shared builds are enabled at this
point, since they are the ones passing.  Builds that are statically linked
still show some issues in some of the eal_flags tests.  Additionally,
the command to invoke fast tests includes a timeout multiplier, since
some CI environments don't have enough resources to complete the tests in
the default 10s timeout period.

Signed-off-by: Aaron Conole <aconole@redhat.com>
---
 .ci/linux-build.sh | 8 ++++++++
 .ci/linux-setup.sh | 8 +++++++-
 .travis.yml        | 9 ++++++++-
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index d5783c1a4..75f740648 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -22,3 +22,11 @@ fi
 OPTS="$OPTS --default-library=$DEF_LIB"
 meson build --werror -Dexamples=all $OPTS
 ninja -C build
+
+if [ "$RUN_TESTS" = "1" ]; then
+    # On the test build, also build the documentation, since it's expensive
+    # and we shouldn't need to build so much of it.
+    ninja -C build doc
+
+    sudo meson test -C build --suite fast-tests -t 3
+fi
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
index acdf9f370..a40e62eaa 100755
--- a/.ci/linux-setup.sh
+++ b/.ci/linux-setup.sh
@@ -1,3 +1,9 @@
 #!/bin/sh
 
-python3 -m pip install --upgrade meson --user
+# need to install as 'root' since some of the unit tests won't run without it
+sudo python3 -m pip install --upgrade meson
+
+# setup hugepages
+cat /proc/meminfo
+sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
+cat /proc/meminfo
diff --git a/.travis.yml b/.travis.yml
index 7b167fa64..c0c27bb7f 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -30,6 +30,7 @@ env:
   - DEF_LIB="shared"
   - DEF_LIB="static" OPTS="-Denable_kmods=false"
   - DEF_LIB="shared" OPTS="-Denable_kmods=false"
+  - DEF_LIB="shared" RUN_TESTS=1
 
 matrix:
   include:
@@ -51,7 +52,7 @@ matrix:
       apt:
         packages:
           - *extra_packages
-  - env: DEF_LIB="shared" EXTRA_PACKAGES=1
+  - env: DEF_LIB="shared" EXTRA_PACKAGES=1 RUN_TESTS=1
     compiler: gcc
     addons:
       apt:
@@ -81,6 +82,12 @@ matrix:
       apt:
         packages:
           - *extra_packages
+  - env: DEF_LIB="shared" EXTRA_PACKAGES=1 RUN_TESTS=1
+    compiler: clang
+    addons:
+      apt:
+        packages:
+          - *extra_packages
   - env: DEF_LIB="static" OPTS="-Denable_kmods=false" EXTRA_PACKAGES=1
     compiler: clang
     addons:
-- 
2.21.0

Re: [dpdk-dev] [PATCH 2/2] ci: enable unit tests under travis-ci

[Michael Santana Francisco]

On Wed, Jul 31, 2019 at 10:50 AM Aaron Conole <aconole@redhat.com> wrote:
>
> When building under Travis (or another linux CI service), enable running the
> fast-tests for selected builds.  Only the shared builds are enabled at this
> point, since they are the ones passing.  Builds that are statically linked
> still show some issues in some of the eal_flags tests.  Additionally,
> the command to invoke fast tests includes a timeout multiplier, since
> some CI environments don't have enough resources to complete the tests in
> the default 10s timeout period.
>
> Signed-off-by: Aaron Conole <aconole@redhat.com>
> ---
>  .ci/linux-build.sh | 8 ++++++++
>  .ci/linux-setup.sh | 8 +++++++-
>  .travis.yml        | 9 ++++++++-
>  3 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
> index d5783c1a4..75f740648 100755
> --- a/.ci/linux-build.sh
> +++ b/.ci/linux-build.sh
> @@ -22,3 +22,11 @@ fi
>  OPTS="$OPTS --default-library=$DEF_LIB"
>  meson build --werror -Dexamples=all $OPTS
>  ninja -C build
> +
> +if [ "$RUN_TESTS" = "1" ]; then
> +    # On the test build, also build the documentation, since it's expensive
> +    # and we shouldn't need to build so much of it.
> +    ninja -C build doc
> +
> +    sudo meson test -C build --suite fast-tests -t 3
> +fi
> diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
> index acdf9f370..a40e62eaa 100755
> --- a/.ci/linux-setup.sh
> +++ b/.ci/linux-setup.sh
> @@ -1,3 +1,9 @@
>  #!/bin/sh
>
> -python3 -m pip install --upgrade meson --user
> +# need to install as 'root' since some of the unit tests won't run without it
> +sudo python3 -m pip install --upgrade meson
> +
> +# setup hugepages
> +cat /proc/meminfo
> +sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> +cat /proc/meminfo
Can we drop cat /proc/meminfo?
> diff --git a/.travis.yml b/.travis.yml
> index 7b167fa64..c0c27bb7f 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -30,6 +30,7 @@ env:
>    - DEF_LIB="shared"
>    - DEF_LIB="static" OPTS="-Denable_kmods=false"
>    - DEF_LIB="shared" OPTS="-Denable_kmods=false"
> +  - DEF_LIB="shared" RUN_TESTS=1
I don't agree with this. This is redundant. Why not put RUN_TESTS=1 on
an already exiting builds instead of adding two new builds like you
are doing here?
A build without the tests takes ~7 minutes, with the tests it
increases to ~9 minutes. These two new builds add ~18 minutes of build
time to the entire travis build time. We could use this ~18 minutes
instead to run the tests on 6 to 9 already existing builds since they
take 2 to 3 extra minutes on each one.
>
>  matrix:
>    include:
> @@ -51,7 +52,7 @@ matrix:
>        apt:
>          packages:
>            - *extra_packages
> -  - env: DEF_LIB="shared" EXTRA_PACKAGES=1
> +  - env: DEF_LIB="shared" EXTRA_PACKAGES=1 RUN_TESTS=1
>      compiler: gcc
>      addons:
>        apt:
> @@ -81,6 +82,12 @@ matrix:
>        apt:
>          packages:
>            - *extra_packages
> +  - env: DEF_LIB="shared" EXTRA_PACKAGES=1 RUN_TESTS=1
> +    compiler: clang
> +    addons:
> +      apt:
> +        packages:
> +          - *extra_packages
>    - env: DEF_LIB="static" OPTS="-Denable_kmods=false" EXTRA_PACKAGES=1
>      compiler: clang
>      addons:
> --
> 2.21.0
>

Re: [dpdk-dev] [PATCH 2/2] ci: enable unit tests under travis-ci

[Aaron Conole]

Michael Santana Francisco <msantana@redhat.com> writes:

> On Wed, Jul 31, 2019 at 10:50 AM Aaron Conole <aconole@redhat.com> wrote:
>>
>> When building under Travis (or another linux CI service), enable running the
>> fast-tests for selected builds.  Only the shared builds are enabled at this
>> point, since they are the ones passing.  Builds that are statically linked
>> still show some issues in some of the eal_flags tests.  Additionally,
>> the command to invoke fast tests includes a timeout multiplier, since
>> some CI environments don't have enough resources to complete the tests in
>> the default 10s timeout period.
>>
>> Signed-off-by: Aaron Conole <aconole@redhat.com>
>> ---
>>  .ci/linux-build.sh | 8 ++++++++
>>  .ci/linux-setup.sh | 8 +++++++-
>>  .travis.yml        | 9 ++++++++-
>>  3 files changed, 23 insertions(+), 2 deletions(-)
>>
>> diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
>> index d5783c1a4..75f740648 100755
>> --- a/.ci/linux-build.sh
>> +++ b/.ci/linux-build.sh
>> @@ -22,3 +22,11 @@ fi
>>  OPTS="$OPTS --default-library=$DEF_LIB"
>>  meson build --werror -Dexamples=all $OPTS
>>  ninja -C build
>> +
>> +if [ "$RUN_TESTS" = "1" ]; then
>> +    # On the test build, also build the documentation, since it's expensive
>> +    # and we shouldn't need to build so much of it.
>> +    ninja -C build doc
>> +
>> +    sudo meson test -C build --suite fast-tests -t 3
>> +fi
>> diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
>> index acdf9f370..a40e62eaa 100755
>> --- a/.ci/linux-setup.sh
>> +++ b/.ci/linux-setup.sh
>> @@ -1,3 +1,9 @@
>>  #!/bin/sh
>>
>> -python3 -m pip install --upgrade meson --user
>> +# need to install as 'root' since some of the unit tests won't run without it
>> +sudo python3 -m pip install --upgrade meson
>> +
>> +# setup hugepages
>> +cat /proc/meminfo
>> +sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
>> +cat /proc/meminfo
> Can we drop cat /proc/meminfo?
>> diff --git a/.travis.yml b/.travis.yml
>> index 7b167fa64..c0c27bb7f 100644
>> --- a/.travis.yml
>> +++ b/.travis.yml
>> @@ -30,6 +30,7 @@ env:
>>    - DEF_LIB="shared"
>>    - DEF_LIB="static" OPTS="-Denable_kmods=false"
>>    - DEF_LIB="shared" OPTS="-Denable_kmods=false"
>> +  - DEF_LIB="shared" RUN_TESTS=1
> I don't agree with this. This is redundant. Why not put RUN_TESTS=1 on
> an already exiting builds instead of adding two new builds like you
> are doing here?
> A build without the tests takes ~7 minutes, with the tests it
> increases to ~9 minutes. These two new builds add ~18 minutes of build
> time to the entire travis build time. We could use this ~18 minutes
> instead to run the tests on 6 to 9 already existing builds since they
> take 2 to 3 extra minutes on each one.

Hi Michael,

The ovsrobot was off for a bit due to an internal issue.  Now that it's
back, a new build was generated.  Please have a look.  The time delta is
about 8-12 minutes (because builds are in parallel) for a complete run
(that's with all of the various jobs which make up a build).

Do you think it's unreasonable?

-Aaron

Re: [dpdk-dev] [PATCH 2/2] ci: enable unit tests under travis-ci

[Michael Santana Francisco]

On Fri, Aug 2, 2019 at 9:34 AM Aaron Conole <aconole@redhat.com> wrote:
>
> Michael Santana Francisco <msantana@redhat.com> writes:
>
> > On Wed, Jul 31, 2019 at 10:50 AM Aaron Conole <aconole@redhat.com> wrote:
> >>
> >> When building under Travis (or another linux CI service), enable running the
> >> fast-tests for selected builds.  Only the shared builds are enabled at this
> >> point, since they are the ones passing.  Builds that are statically linked
> >> still show some issues in some of the eal_flags tests.  Additionally,
> >> the command to invoke fast tests includes a timeout multiplier, since
> >> some CI environments don't have enough resources to complete the tests in
> >> the default 10s timeout period.
> >>
> >> Signed-off-by: Aaron Conole <aconole@redhat.com>
> >> ---
> >>  .ci/linux-build.sh | 8 ++++++++
> >>  .ci/linux-setup.sh | 8 +++++++-
> >>  .travis.yml        | 9 ++++++++-
> >>  3 files changed, 23 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
> >> index d5783c1a4..75f740648 100755
> >> --- a/.ci/linux-build.sh
> >> +++ b/.ci/linux-build.sh
> >> @@ -22,3 +22,11 @@ fi
> >>  OPTS="$OPTS --default-library=$DEF_LIB"
> >>  meson build --werror -Dexamples=all $OPTS
> >>  ninja -C build
> >> +
> >> +if [ "$RUN_TESTS" = "1" ]; then
> >> +    # On the test build, also build the documentation, since it's expensive
> >> +    # and we shouldn't need to build so much of it.
> >> +    ninja -C build doc
> >> +
> >> +    sudo meson test -C build --suite fast-tests -t 3
> >> +fi
> >> diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
> >> index acdf9f370..a40e62eaa 100755
> >> --- a/.ci/linux-setup.sh
> >> +++ b/.ci/linux-setup.sh
> >> @@ -1,3 +1,9 @@
> >>  #!/bin/sh
> >>
> >> -python3 -m pip install --upgrade meson --user
> >> +# need to install as 'root' since some of the unit tests won't run without it
> >> +sudo python3 -m pip install --upgrade meson
> >> +
> >> +# setup hugepages
> >> +cat /proc/meminfo
> >> +sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
> >> +cat /proc/meminfo
> > Can we drop cat /proc/meminfo?
> >> diff --git a/.travis.yml b/.travis.yml
> >> index 7b167fa64..c0c27bb7f 100644
> >> --- a/.travis.yml
> >> +++ b/.travis.yml
> >> @@ -30,6 +30,7 @@ env:
> >>    - DEF_LIB="shared"
> >>    - DEF_LIB="static" OPTS="-Denable_kmods=false"
> >>    - DEF_LIB="shared" OPTS="-Denable_kmods=false"
> >> +  - DEF_LIB="shared" RUN_TESTS=1
> > I don't agree with this. This is redundant. Why not put RUN_TESTS=1 on
> > an already exiting builds instead of adding two new builds like you
> > are doing here?
> > A build without the tests takes ~7 minutes, with the tests it
> > increases to ~9 minutes. These two new builds add ~18 minutes of build
> > time to the entire travis build time. We could use this ~18 minutes
> > instead to run the tests on 6 to 9 already existing builds since they
> > take 2 to 3 extra minutes on each one.
>
> Hi Michael,
>
> The ovsrobot was off for a bit due to an internal issue.  Now that it's
> back, a new build was generated.  Please have a look.  The time delta is
> about 8-12 minutes (because builds are in parallel) for a complete run
> (that's with all of the various jobs which make up a build).
>
> Do you think it's unreasonable?
This is reasonable. I didn't take parallelism into account. This looks
better now

Acked-by: Michael Santana <msantana@redhat.com>
>
> -Aaron

Re: [dpdk-dev] [PATCH 2/2] ci: enable unit tests under travis-ci

[Thomas Monjalon]

31/07/2019 22:54, Michael Santana Francisco:
> On Wed, Jul 31, 2019 at 10:50 AM Aaron Conole <aconole@redhat.com> wrote:
> > --- a/.ci/linux-build.sh
> > +++ b/.ci/linux-build.sh
> > @@ -22,3 +22,11 @@ fi
> >  OPTS="$OPTS --default-library=$DEF_LIB"
> >  meson build --werror -Dexamples=all $OPTS
> >  ninja -C build
> > +
> > +if [ "$RUN_TESTS" = "1" ]; then
> > +    # On the test build, also build the documentation, since it's expensive
> > +    # and we shouldn't need to build so much of it.
> > +    ninja -C build doc

I am not sure to understand the comment.
Do you mean you build the documentation only once,
which is when running tests?
Why it is not a new option similar as RUN_TESTS?

> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -30,6 +30,7 @@ env:
> >    - DEF_LIB="shared"
> >    - DEF_LIB="static" OPTS="-Denable_kmods=false"
> >    - DEF_LIB="shared" OPTS="-Denable_kmods=false"
> > +  - DEF_LIB="shared" RUN_TESTS=1
> I don't agree with this. This is redundant. Why not put RUN_TESTS=1 on
> an already exiting builds instead of adding two new builds like you
> are doing here?

I agree it is a strange logic.
Why not use an existing build to run the tests?

Re: [dpdk-dev] [PATCH 2/2] ci: enable unit tests under travis-ci

[Aaron Conole]

Thomas Monjalon <thomas@monjalon.net> writes:

> 31/07/2019 22:54, Michael Santana Francisco:
>> On Wed, Jul 31, 2019 at 10:50 AM Aaron Conole <aconole@redhat.com> wrote:
>> > --- a/.ci/linux-build.sh
>> > +++ b/.ci/linux-build.sh
>> > @@ -22,3 +22,11 @@ fi
>> >  OPTS="$OPTS --default-library=$DEF_LIB"
>> >  meson build --werror -Dexamples=all $OPTS
>> >  ninja -C build
>> > +
>> > +if [ "$RUN_TESTS" = "1" ]; then
>> > +    # On the test build, also build the documentation, since it's expensive
>> > +    # and we shouldn't need to build so much of it.
>> > +    ninja -C build doc
>
> I am not sure to understand the comment.
> Do you mean you build the documentation only once,
> which is when running tests?

Yes.

> Why it is not a new option similar as RUN_TESTS?

I mentioned it at:
http://mails.dpdk.org/archives/dev/2019-July/136635.html also.  Because
it adds build time.

>> > --- a/.travis.yml
>> > +++ b/.travis.yml
>> > @@ -30,6 +30,7 @@ env:
>> >    - DEF_LIB="shared"
>> >    - DEF_LIB="static" OPTS="-Denable_kmods=false"
>> >    - DEF_LIB="shared" OPTS="-Denable_kmods=false"
>> > +  - DEF_LIB="shared" RUN_TESTS=1
>> I don't agree with this. This is redundant. Why not put RUN_TESTS=1 on
>> an already exiting builds instead of adding two new builds like you
>> are doing here?
>
> I agree it is a strange logic.
> Why not use an existing build to run the tests?

The biggest reason is when it fails, it is difficult to know why "at a
glance."  When it does fail due to unit tests, it sometimes takes a
long time to load the logs - so just knowing that the failure is likely
in the unit tests area vs. build is helpful to understand where to start
looking.

It isn't a big deal to merge them, though if you'd prefer it.

Re: [dpdk-dev] [PATCH 2/2] ci: enable unit tests under travis-ci

[Thomas Monjalon]

02/08/2019 22:59, Aaron Conole:
> Thomas Monjalon <thomas@monjalon.net> writes:
> > 31/07/2019 22:54, Michael Santana Francisco:
> >> On Wed, Jul 31, 2019 at 10:50 AM Aaron Conole <aconole@redhat.com> wrote:
> >> > --- a/.ci/linux-build.sh
> >> > +++ b/.ci/linux-build.sh
> >> > @@ -22,3 +22,11 @@ fi
> >> >  OPTS="$OPTS --default-library=$DEF_LIB"
> >> >  meson build --werror -Dexamples=all $OPTS
> >> >  ninja -C build
> >> > +
> >> > +if [ "$RUN_TESTS" = "1" ]; then
> >> > +    # On the test build, also build the documentation, since it's expensive
> >> > +    # and we shouldn't need to build so much of it.
> >> > +    ninja -C build doc
> >
> > I am not sure to understand the comment.
> > Do you mean you build the documentation only once,
> > which is when running tests?
> 
> Yes.
> 
> > Why it is not a new option similar as RUN_TESTS?
> 
> I mentioned it at:
> http://mails.dpdk.org/archives/dev/2019-July/136635.html also.  Because
> it adds build time.

I don't understand.
If you set RUN_TESTS and BUILD_DOCS on the same build,
how is it adding build time?
I'm just suggesting to make explicit that tests and docs
are done in the same run.

> >> > --- a/.travis.yml
> >> > +++ b/.travis.yml
> >> > @@ -30,6 +30,7 @@ env:
> >> >    - DEF_LIB="shared"
> >> >    - DEF_LIB="static" OPTS="-Denable_kmods=false"
> >> >    - DEF_LIB="shared" OPTS="-Denable_kmods=false"
> >> > +  - DEF_LIB="shared" RUN_TESTS=1
> >> I don't agree with this. This is redundant. Why not put RUN_TESTS=1 on
> >> an already exiting builds instead of adding two new builds like you
> >> are doing here?
> >
> > I agree it is a strange logic.
> > Why not use an existing build to run the tests?
> 
> The biggest reason is when it fails, it is difficult to know why "at a
> glance."  When it does fail due to unit tests, it sometimes takes a
> long time to load the logs - so just knowing that the failure is likely
> in the unit tests area vs. build is helpful to understand where to start
> looking.
> 
> It isn't a big deal to merge them, though if you'd prefer it.

It looks to be a good reason.
I'm just sad that we cannot reuse an existing build in another way.
But I guess the infrastructure cache (ccache or other) will be enough.

Re: [dpdk-dev] [PATCH 2/2] ci: enable unit tests under travis-ci

[Aaron Conole]

Thomas Monjalon <thomas@monjalon.net> writes:

> 02/08/2019 22:59, Aaron Conole:
>> Thomas Monjalon <thomas@monjalon.net> writes:
>> > 31/07/2019 22:54, Michael Santana Francisco:
>> >> On Wed, Jul 31, 2019 at 10:50 AM Aaron Conole <aconole@redhat.com> wrote:
>> >> > --- a/.ci/linux-build.sh
>> >> > +++ b/.ci/linux-build.sh
>> >> > @@ -22,3 +22,11 @@ fi
>> >> >  OPTS="$OPTS --default-library=$DEF_LIB"
>> >> >  meson build --werror -Dexamples=all $OPTS
>> >> >  ninja -C build
>> >> > +
>> >> > +if [ "$RUN_TESTS" = "1" ]; then
>> >> > +    # On the test build, also build the documentation, since it's expensive
>> >> > +    # and we shouldn't need to build so much of it.
>> >> > +    ninja -C build doc
>> >
>> > I am not sure to understand the comment.
>> > Do you mean you build the documentation only once,
>> > which is when running tests?
>> 
>> Yes.
>> 
>> > Why it is not a new option similar as RUN_TESTS?
>> 
>> I mentioned it at:
>> http://mails.dpdk.org/archives/dev/2019-July/136635.html also.  Because
>> it adds build time.
>
> I don't understand.
> If you set RUN_TESTS and BUILD_DOCS on the same build,
> how is it adding build time?
> I'm just suggesting to make explicit that tests and docs
> are done in the same run.

Sure I'll do that - it's not like I need to mine a new environment
variable from somewhere. :)

>> >> > --- a/.travis.yml
>> >> > +++ b/.travis.yml
>> >> > @@ -30,6 +30,7 @@ env:
>> >> >    - DEF_LIB="shared"
>> >> >    - DEF_LIB="static" OPTS="-Denable_kmods=false"
>> >> >    - DEF_LIB="shared" OPTS="-Denable_kmods=false"
>> >> > +  - DEF_LIB="shared" RUN_TESTS=1
>> >> I don't agree with this. This is redundant. Why not put RUN_TESTS=1 on
>> >> an already exiting builds instead of adding two new builds like you
>> >> are doing here?
>> >
>> > I agree it is a strange logic.
>> > Why not use an existing build to run the tests?
>> 
>> The biggest reason is when it fails, it is difficult to know why "at a
>> glance."  When it does fail due to unit tests, it sometimes takes a
>> long time to load the logs - so just knowing that the failure is likely
>> in the unit tests area vs. build is helpful to understand where to start
>> looking.
>> 
>> It isn't a big deal to merge them, though if you'd prefer it.
>
> It looks to be a good reason.
> I'm just sad that we cannot reuse an existing build in another way.
> But I guess the infrastructure cache (ccache or other) will be enough.

Re: [dpdk-dev] [PATCH 0/2] Enable fast-unit tests under travis

[David Marchand]

On Wed, Jul 31, 2019 at 4:50 PM Aaron Conole <aconole@redhat.com> wrote:
>
> This series turns the fast unit tests on for a limited set of
> builds under the travis build system.  An example run is available
> at:
>
> https://travis-ci.org/orgcandman/dpdk/builds/565991679
>
> The builds which execute the unit tests may be distinguished by the
> "RUN_TESTS" parameter.
>
> Aaron Conole (1):
>   ci: enable unit tests under travis-ci
>
> Michael Santana (1):
>   tests: Fix unit tests for shared builds
>
>  .ci/linux-build.sh   | 8 ++++++++
>  .ci/linux-setup.sh   | 8 +++++++-
>  .travis.yml          | 9 ++++++++-
>  app/test/meson.build | 9 +++++++++
>  4 files changed, 32 insertions(+), 2 deletions(-)
>
> --
> 2.21.0
>

For the series,
Reviewed-by: David Marchand <david.marchand@redhat.com>


-- 
David Marchand

[dpdk-dev] [PATCH v2 0/2] Enable fast-unit tests under travis

[Aaron Conole]

This series turns the fast unit tests on for a limited set of
builds under the travis build system.  An example run is available
at:

https://travis-ci.org/orgcandman/dpdk/builds/565991679

The builds which execute the unit tests may be distinguished by the
"RUN_TESTS" parameter.

Aaron Conole (1):
  ci: enable unit tests under travis-ci

Michael Santana (1):
  tests: Fix unit tests for shared builds

 .ci/linux-build.sh   |  8 ++++++++
 .ci/linux-setup.sh   |  8 +++++++-
 .travis.yml          |  9 ++++++++-
 app/test/meson.build | 13 +++++++++++++
 4 files changed, 36 insertions(+), 2 deletions(-)

-- 
2.21.0

[dpdk-dev] [PATCH v2 1/2] tests: Fix unit tests for shared builds

[Aaron Conole]

From: Michael Santana <msantana@redhat.com>

Currently many unit tests fail when running tests under shared builds.
This happens because of missing driver dependencies. This is fixed by
explicitly linking in missing drivers for the test application.

before and after (clang):
https://travis-ci.com/Maickii/dpdk-2/jobs/212329160#L623
https://travis-ci.com/Maickii/dpdk-2/jobs/212335912#L620

Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
Suggested-by: David Marchand <david.marchand@redhat.com>
Signed-off-by: Michael Santana <msantana@redhat.com>
Signed-off-by: Aaron Conole <aconole@redhat.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
Reviewed-by: David Marchand <david.marchand at redhat.com>
---
 app/test/meson.build | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/app/test/meson.build b/app/test/meson.build
index e8a898eb6..8afd21dff 100644
--- a/app/test/meson.build
+++ b/app/test/meson.build
@@ -297,6 +297,19 @@ dump_test_names = [
         'dump_memzone',
 ]
 
+# The following linkages are an exception to allow running the
+# unit tests without requiring that the developer install the
+# DPDK libraries.  Explicit linkage in applications should not
+# be used.
+if dpdk_conf.has('RTE_LIBRTE_RING_MEMPOOL')
+	test_deps += 'mempool_ring'
+endif
+if dpdk_conf.has('RTE_LIBRTE_STACK_MEMPOOL')
+	test_deps += 'mempool_stack'
+endif
+if dpdk_conf.has('RTE_LIBRTE_SKELETON_EVENTDEV_PMD')
+	test_deps += 'pmd_skeleton_event'
+endif
 if dpdk_conf.has('RTE_LIBRTE_PDUMP')
 	test_deps += 'pdump'
 endif
-- 
2.21.0

Re: [dpdk-dev] [PATCH v2 1/2] tests: Fix unit tests for shared builds

[Thomas Monjalon]

02/08/2019 23:25, Aaron Conole:
> From: Michael Santana <msantana@redhat.com>
> 
> Currently many unit tests fail when running tests under shared builds.
> This happens because of missing driver dependencies. This is fixed by
> explicitly linking in missing drivers for the test application.
> 
> before and after (clang):
> https://travis-ci.com/Maickii/dpdk-2/jobs/212329160#L623
> https://travis-ci.com/Maickii/dpdk-2/jobs/212335912#L620
> 
> Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
> Suggested-by: David Marchand <david.marchand@redhat.com>
> Signed-off-by: Michael Santana <msantana@redhat.com>
> Signed-off-by: Aaron Conole <aconole@redhat.com>
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> Reviewed-by: David Marchand <david.marchand at redhat.com>
> ---
>  app/test/meson.build | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/app/test/meson.build b/app/test/meson.build
> index e8a898eb6..8afd21dff 100644
> --- a/app/test/meson.build
> +++ b/app/test/meson.build
> +# The following linkages are an exception to allow running the
> +# unit tests without requiring that the developer install the
> +# DPDK libraries.  Explicit linkage in applications should not
> +# be used.
> +if dpdk_conf.has('RTE_LIBRTE_RING_MEMPOOL')
> +	test_deps += 'mempool_ring'
> +endif
> +if dpdk_conf.has('RTE_LIBRTE_STACK_MEMPOOL')
> +	test_deps += 'mempool_stack'
> +endif
> +if dpdk_conf.has('RTE_LIBRTE_SKELETON_EVENTDEV_PMD')
> +	test_deps += 'pmd_skeleton_event'
> +endif
>  if dpdk_conf.has('RTE_LIBRTE_PDUMP')
>  	test_deps += 'pdump'
>  endif

I did some changes in comments and line spacing, so it looks like below.
Sorry for doing this change myself, I want to allow you running this CI
as soon as possible.

# The following linkages are an exception to allow running the
# unit tests without requiring that the developer install the
# DPDK libraries.  Explicit linkage of drivers (plugin libraries)
# in applications should not be used.
if dpdk_conf.has('RTE_LIBRTE_RING_MEMPOOL')
    test_deps += 'mempool_ring'
endif
if dpdk_conf.has('RTE_LIBRTE_STACK_MEMPOOL')
    test_deps += 'mempool_stack'
endif
if dpdk_conf.has('RTE_LIBRTE_SKELETON_EVENTDEV_PMD')
    test_deps += 'pmd_skeleton_event'
endif

# The following linkages of drivers are required because
# they are used via a driver-specific API.
if dpdk_conf.has('RTE_LIBRTE_BOND_PMD')
    test_deps += 'pmd_bond'
endif
if dpdk_conf.has('RTE_LIBRTE_RING_PMD')
    test_deps += 'pmd_ring'
endif

if dpdk_conf.has('RTE_LIBRTE_POWER')
    test_deps += 'power'
endif
if dpdk_conf.has('RTE_LIBRTE_KNI')
    test_deps += 'kni'
endif
if dpdk_conf.has('RTE_LIBRTE_PDUMP')
    test_deps += 'pdump'
endif

[dpdk-dev] [PATCH v2 2/2] ci: enable unit tests under travis-ci

[Aaron Conole]

When building under Travis (or another linux CI service), enable
running the fast-tests when the RUN_TESTS environment variable is set.

For the Travis service, introduce two new shared builds, since the
shared builds are the ones passing.  Builds that are statically
linked still show some issues in some of the eal_flags tests.  We make
new builds for this, rather than piggybacking, because 'at a glance'
it is difficult to determine why a build fails, and if tests were
enabled for all builds, then looking at the logs for any build would
take a significant amount of time.

Finally, the command to invoke fast tests includes a timeout
multiplier, since some CI environments don't have enough resources to
complete the tests in the default 10s timeout period.

Signed-off-by: Aaron Conole <aconole@redhat.com>
Acked-by: Michael Santana <msantana@redhat.com>
Reviewed-by: David Marchand <david.marchand at redhat.com>
---
 .ci/linux-build.sh | 8 ++++++++
 .ci/linux-setup.sh | 8 +++++++-
 .travis.yml        | 9 ++++++++-
 3 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/.ci/linux-build.sh b/.ci/linux-build.sh
index d5783c1a4..d5ad919d1 100755
--- a/.ci/linux-build.sh
+++ b/.ci/linux-build.sh
@@ -22,3 +22,11 @@ fi
 OPTS="$OPTS --default-library=$DEF_LIB"
 meson build --werror -Dexamples=all $OPTS
 ninja -C build
+
+if [ "$BUILD_DOCS" = "1" ]; then
+    ninja -C build doc
+fi
+
+if [ "$RUN_TESTS" = "1" ]; then
+    sudo meson test -C build --suite fast-tests -t 3
+fi
diff --git a/.ci/linux-setup.sh b/.ci/linux-setup.sh
index acdf9f370..a40e62eaa 100755
--- a/.ci/linux-setup.sh
+++ b/.ci/linux-setup.sh
@@ -1,3 +1,9 @@
 #!/bin/sh
 
-python3 -m pip install --upgrade meson --user
+# need to install as 'root' since some of the unit tests won't run without it
+sudo python3 -m pip install --upgrade meson
+
+# setup hugepages
+cat /proc/meminfo
+sudo sh -c 'echo 1024 > /proc/sys/vm/nr_hugepages'
+cat /proc/meminfo
diff --git a/.travis.yml b/.travis.yml
index 7b167fa64..781f9f666 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -30,6 +30,7 @@ env:
   - DEF_LIB="shared"
   - DEF_LIB="static" OPTS="-Denable_kmods=false"
   - DEF_LIB="shared" OPTS="-Denable_kmods=false"
+  - DEF_LIB="shared" RUN_TESTS=1 BUILD_DOCS=1
 
 matrix:
   include:
@@ -51,7 +52,7 @@ matrix:
       apt:
         packages:
           - *extra_packages
-  - env: DEF_LIB="shared" EXTRA_PACKAGES=1
+  - env: DEF_LIB="shared" EXTRA_PACKAGES=1 RUN_TESTS=1 BUILD_DOCS=1
     compiler: gcc
     addons:
       apt:
@@ -81,6 +82,12 @@ matrix:
       apt:
         packages:
           - *extra_packages
+  - env: DEF_LIB="shared" EXTRA_PACKAGES=1 RUN_TESTS=1 BUILD_DOCS=1
+    compiler: clang
+    addons:
+      apt:
+        packages:
+          - *extra_packages
   - env: DEF_LIB="static" OPTS="-Denable_kmods=false" EXTRA_PACKAGES=1
     compiler: clang
     addons:
-- 
2.21.0

Re: [dpdk-dev] [PATCH v2 0/2] Enable fast-unit tests under travis

[Thomas Monjalon]

02/08/2019 23:25, Aaron Conole:
> This series turns the fast unit tests on for a limited set of
> builds under the travis build system.  An example run is available
> at:
> 
> https://travis-ci.org/orgcandman/dpdk/builds/565991679
> 
> The builds which execute the unit tests may be distinguished by the
> "RUN_TESTS" parameter.
> 
> Aaron Conole (1):
>   ci: enable unit tests under travis-ci
> 
> Michael Santana (1):
>   tests: Fix unit tests for shared builds

Applied with change in comments of first patch, as described in this thread.
Thanks

Next step: Get Travis reports in patchwork :)

Re: [dpdk-dev] [PATCH v2 0/2] Enable fast-unit tests under travis

[David Marchand]

On Sat, Aug 3, 2019 at 12:00 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>
> 02/08/2019 23:25, Aaron Conole:
> > This series turns the fast unit tests on for a limited set of
> > builds under the travis build system.  An example run is available
> > at:
> >
> > https://travis-ci.org/orgcandman/dpdk/builds/565991679
> >
> > The builds which execute the unit tests may be distinguished by the
> > "RUN_TESTS" parameter.
> >
> > Aaron Conole (1):
> >   ci: enable unit tests under travis-ci
> >
> > Michael Santana (1):
> >   tests: Fix unit tests for shared builds
>
> Applied with change in comments of first patch, as described in this thread.
> Thanks

Not sure I understand this error:
https://travis-ci.com/DPDK/dpdk/jobs/222141682

The 'static' config worked fine:
https://travis-ci.com/DPDK/dpdk/jobs/222141683


Maybe a network issue ? But I would expect some kind of related
warning/error message.


-- 
David Marchand

Re: [dpdk-dev] [PATCH v2 0/2] Enable fast-unit tests under travis

[David Marchand]

On Mon, Aug 5, 2019 at 8:26 AM David Marchand <david.marchand@redhat.com> wrote:
>
> On Sat, Aug 3, 2019 at 12:00 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 02/08/2019 23:25, Aaron Conole:
> > > This series turns the fast unit tests on for a limited set of
> > > builds under the travis build system.  An example run is available
> > > at:
> > >
> > > https://travis-ci.org/orgcandman/dpdk/builds/565991679
> > >
> > > The builds which execute the unit tests may be distinguished by the
> > > "RUN_TESTS" parameter.
> > >
> > > Aaron Conole (1):
> > >   ci: enable unit tests under travis-ci
> > >
> > > Michael Santana (1):
> > >   tests: Fix unit tests for shared builds
> >
> > Applied with change in comments of first patch, as described in this thread.
> > Thanks
>
> Not sure I understand this error:
> https://travis-ci.com/DPDK/dpdk/jobs/222141682
>
> The 'static' config worked fine:
> https://travis-ci.com/DPDK/dpdk/jobs/222141683
>
>
> Maybe a network issue ? But I would expect some kind of related
> warning/error message.
>

Ah something like those messages:
https://travis-ci.com/DPDK/dpdk/jobs/222407326
https://travis-ci.com/DPDK/dpdk/jobs/222417471

Is there a way to retry builds?
Automatically?


-- 
David Marchand

Re: [dpdk-dev] [PATCH v2 0/2] Enable fast-unit tests under travis

[Michael Santana Francisco]

On Mon, Aug 5, 2019 at 8:52 AM David Marchand <david.marchand@redhat.com> wrote:
>
> On Mon, Aug 5, 2019 at 8:26 AM David Marchand <david.marchand@redhat.com> wrote:
> >
> > On Sat, Aug 3, 2019 at 12:00 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> > >
> > > 02/08/2019 23:25, Aaron Conole:
> > > > This series turns the fast unit tests on for a limited set of
> > > > builds under the travis build system.  An example run is available
> > > > at:
> > > >
> > > > https://travis-ci.org/orgcandman/dpdk/builds/565991679
> > > >
> > > > The builds which execute the unit tests may be distinguished by the
> > > > "RUN_TESTS" parameter.
> > > >
> > > > Aaron Conole (1):
> > > >   ci: enable unit tests under travis-ci
> > > >
> > > > Michael Santana (1):
> > > >   tests: Fix unit tests for shared builds
> > >
> > > Applied with change in comments of first patch, as described in this thread.
> > > Thanks
> >
> > Not sure I understand this error:
> > https://travis-ci.com/DPDK/dpdk/jobs/222141682
> >
> > The 'static' config worked fine:
> > https://travis-ci.com/DPDK/dpdk/jobs/222141683
> >
> >
> > Maybe a network issue ? But I would expect some kind of related
> > warning/error message.
It's either that or some other issue with the travis infrastructure.
There is nothing wrong in our end which is the frustrating part. I am
being hopeful and optimistic that it's _just a hiccup_ and it will go
away on its own. If it really keeps happening then we might need to
report the issue to travis
> >
>
> Ah something like those messages:
> https://travis-ci.com/DPDK/dpdk/jobs/222407326
> https://travis-ci.com/DPDK/dpdk/jobs/222417471
>
> Is there a way to retry builds?
Yes, at the very top, to the right there is a 'Restart job' button.
You have to be logged in as the owner of the repo to be able to see it
and click on it. That will restart the job from the very start.
> Automatically?
That's the million dollar question. We'll have to investigate if it's possible
>
>
> --
> David Marchand

Re: [dpdk-dev] [PATCH v2 0/2] Enable fast-unit tests under travis

[Aaron Conole]

Michael Santana Francisco <msantana@redhat.com> writes:

> On Mon, Aug 5, 2019 at 8:52 AM David Marchand <david.marchand@redhat.com> wrote:
>>
>> On Mon, Aug 5, 2019 at 8:26 AM David Marchand <david.marchand@redhat.com> wrote:
>> >
>> > On Sat, Aug 3, 2019 at 12:00 AM Thomas Monjalon <thomas@monjalon.net> wrote:
>> > >
>> > > 02/08/2019 23:25, Aaron Conole:
>> > > > This series turns the fast unit tests on for a limited set of
>> > > > builds under the travis build system.  An example run is available
>> > > > at:
>> > > >
>> > > > https://travis-ci.org/orgcandman/dpdk/builds/565991679
>> > > >
>> > > > The builds which execute the unit tests may be distinguished by the
>> > > > "RUN_TESTS" parameter.
>> > > >
>> > > > Aaron Conole (1):
>> > > >   ci: enable unit tests under travis-ci
>> > > >
>> > > > Michael Santana (1):
>> > > >   tests: Fix unit tests for shared builds
>> > >
>> > > Applied with change in comments of first patch, as described in this thread.
>> > > Thanks
>> >
>> > Not sure I understand this error:
>> > https://travis-ci.com/DPDK/dpdk/jobs/222141682
>> >
>> > The 'static' config worked fine:
>> > https://travis-ci.com/DPDK/dpdk/jobs/222141683
>> >
>> >
>> > Maybe a network issue ? But I would expect some kind of related
>> > warning/error message.
> It's either that or some other issue with the travis infrastructure.
> There is nothing wrong in our end which is the frustrating part. I am
> being hopeful and optimistic that it's _just a hiccup_ and it will go
> away on its own. If it really keeps happening then we might need to
> report the issue to travis
>> >
>>
>> Ah something like those messages:
>> https://travis-ci.com/DPDK/dpdk/jobs/222407326
>> https://travis-ci.com/DPDK/dpdk/jobs/222417471
>>
>> Is there a way to retry builds?
> Yes, at the very top, to the right there is a 'Restart job' button.
> You have to be logged in as the owner of the repo to be able to see it
> and click on it. That will restart the job from the very start.
>> Automatically?
> That's the million dollar question. We'll have to investigate if it's
> possible

It's possible.  I need to get the robot polling travis correctly still.

At the moment it can poll, but we don't have enough of the data
recorded.  It's coming though.

One thing I notice is that some of the tests are still failing
'sporadically' and that's difficult to discern.  So we might just use
the robot as 'warn' rather than 'error' for now and maintainers will
have to make a best determination.

>>
>>
>> --
>> David Marchand

Re: [dpdk-dev] [PATCH v2 0/2] Enable fast-unit tests under travis

[Thomas Monjalon]

05/08/2019 16:18, Aaron Conole:
> One thing I notice is that some of the tests are still failing
> 'sporadically' and that's difficult to discern.  So we might just use
> the robot as 'warn' rather than 'error' for now and maintainers will
> have to make a best determination.

Yes it can be a good first step.

Re: [dpdk-dev] [PATCH v2 0/2] Enable fast-unit tests under travis

[Michael Santana Francisco]

On Mon, Aug 5, 2019 at 2:27 AM David Marchand <david.marchand@redhat.com> wrote:
>
> On Sat, Aug 3, 2019 at 12:00 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> >
> > 02/08/2019 23:25, Aaron Conole:
> > > This series turns the fast unit tests on for a limited set of
> > > builds under the travis build system.  An example run is available
> > > at:
> > >
> > > https://travis-ci.org/orgcandman/dpdk/builds/565991679
> > >
> > > The builds which execute the unit tests may be distinguished by the
> > > "RUN_TESTS" parameter.
> > >
> > > Aaron Conole (1):
> > >   ci: enable unit tests under travis-ci
> > >
> > > Michael Santana (1):
> > >   tests: Fix unit tests for shared builds
> >
> > Applied with change in comments of first patch, as described in this thread.
> > Thanks
>
> Not sure I understand this error:
> https://travis-ci.com/DPDK/dpdk/jobs/222141682
>
> The 'static' config worked fine:
> https://travis-ci.com/DPDK/dpdk/jobs/222141683
>
>
> Maybe a network issue ? But I would expect some kind of related
> warning/error message.
It looks like they fixed their network issues

https://www.traviscistatus.com/incidents/hl4vqb7hvv5n
>
>
> --
> David Marchand