Re: [dpdk-dev] [PATCH 00/14] Unit tests fixes for CI

[Michael Santana Francisco <msantana@redhat.com>]

On 6/4/19 4:59 AM, David Marchand wrote:
> This is a joint effort to make the unit tests ready for CI.
> The first 8 patches are fixes that I had accumulated.
> Then the second part of the series focuses on skipping tests when some
> requirements are not fulfilled so that we can start them in a restrained
> environment like Travis virtual machines that gives us two cores and does
> not have specific hw devices.
>
> We are still not ready for enabling those tests in Travis.
> At least, the following issues remain:
> - some fixes on librte_acl have not been merged yet [1],
> - the tests on --file-prefix are still ko, and have been isolated in a
>    test that we could disable while waiting for the fixes,
> - rwlock_autotest and hash_readwrite_lf_autotest are taking a little more
>    than 10s,
It would be a good idea to increase timeout. These are probably not the 
only tests that would pass with just a little bit more time
> - librte_table unit test crashes on ipv6 [2],
> - the "perf" tests are taking way too long for my taste,

We should still fix them. However I don't know if we should be running 
the perf test for every job and every patch on travis. It takes too 
long. The travis queue will be delayed too far behind for it to be of 
any use.

OTOH we could have one job as part of the travis build dedicated to 
running tests (or just perf test). It's still time consuming but better 
than running the test on every travis job. For this to work we would 
need to decreased the timeout for the perf tests as the timeout for it 
and the travis are both 10 minutes

> - the shared build unit tests all fail when depending on mempool since
>    the mempool drivers are not loaded,
>
> 1: http://patchwork.dpdk.org/project/dpdk/list/?series=4242
> 2: https://bugs.dpdk.org/show_bug.cgi?id=285
>
> Comments/reviews welcome!
>