[dpdk-dev] [PATCH v2 00/15] Unit tests fixes for CI

[David Marchand]

On Mon, Jun 17, 2019 at 1:57 PM Bruce Richardson <bruce.richardson at intel.com>
wrote:

> On Mon, Jun 17, 2019 at 01:41:21PM +0200, David Marchand wrote:
> >    On Mon, Jun 17, 2019 at 1:18 PM Bruce Richardson
> >    <[1]bruce.richardson at intel.com> wrote:
> >
> >      On Mon, Jun 17, 2019 at 12:46:03PM +0200, David Marchand wrote:
> >      >    On Mon, Jun 17, 2019 at 12:02 PM Bruce Richardson
> >      >    <[1][2]bruce.richardson at intel.com> wrote:
> >      >
> >      >      On Sat, Jun 15, 2019 at 08:42:15AM +0200, David Marchand
> >      wrote:
> >      >      > This is a joint effort to make the unit tests ready for CI.
> >      >      > The first 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,
> >      >      > - librte_table unit test crashes on ipv6 [2],
> >      >      > - the "perf" tests are taking way too long for my taste,
> >      >      > - the shared build unit tests all fail when depending on
> >      mempool
> >      >      since
> >      >      >   the mempool drivers are not loaded,
> >      >      >
> >      >      For the autotest app shared builds, it is probably worthwhile
> >      >      linking in
> >      >      all drivers explicitly to avoid issues like this.
> >      >
> >      >    Yes, I'll look into this.
> >      >    While at it, do you know why the i40e and ixgbe drivers are
> >      linked to
> >      >    app/test in meson?
> >      >    --
> >      There are unit tests for the device-specific functions in those
> >      drivers, so
> >      they need to be given at link time.
> >
> >    For testpmd, I can understand.
> >    But I can't see code for driver specific apis in app/test.
> >    It looks like a copy/paste error when adding meson support.
> >    --
> Ok, could be. Simple question is does it still build ok if you remove them?
>

It would have been strange if it did not build, since on Makefile side we
do nothing.
Yes, it builds fine with meson without this.

I managed to get the same test results than with static builds by linking
the skeleton eventdev driver and the mempool sw drivers.
Should be enough.



-- 
David Marchand