[dpdk-dev] [PATCH v2 00/15] Unit tests fixes for CI
david.marchand at redhat.com
Mon Jun 17 15:44:41 CEST 2019
On Mon, Jun 17, 2019 at 1:57 PM Bruce Richardson <bruce.richardson at intel.com>
> On Mon, Jun 17, 2019 at 01:41:21PM +0200, David Marchand wrote:
> > On Mon, Jun 17, 2019 at 1:18 PM Bruce Richardson
> > <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
> > > <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 ,
> > > > - 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 ,
> > > > - 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
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.
More information about the dev